home *** CD-ROM | disk | FTP | other *** search
/ Amiga Collections: Amiga Amateur Radio User Group / AARUG UK #17 (199x)(Amiga Amateur Radio User Group UK)(PD)[WB][G4DCV].zip / AARUG UK #17 (199x)(Amiga Amateur Radio User Group UK)(PD)[WB][G4DCV].adf / 890421.1.doc < prev    next >
Text File  |  1990-01-08  |  292KB  |  7,137 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  
  17.             The KA9Q Internet Software Package
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.               Updated for 890421.1 Revision
  28.  
  29.                    May 8, 1989
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.                     by
  43.  
  44.                    Bdale Garbee, N3EUA
  45.  
  46.  
  47.  
  48.              Copyright 1989    by Bdale Garbee.
  49.                    All Rights Reserved.
  50.  
  51.              This Document may be reproduced in    whole
  52.             or in part for any non-commercial purpose,
  53.               as long as credit    is given the author.
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.                       -    2 -
  71.  
  72.  
  73.                   Caveat Emptor
  74.  
  75.      This document is a    major rewrite of the document included with  871225.0
  76.      release  of the KA9Q package, but it is in    the author's opinion very far
  77.      from perfect. I believe that the bulk of the material here    is  factually
  78.      correct,  but the formatting is rough, and    there are no doubt some    juicy
  79.      tidbits missing that should have been included.
  80.  
  81.      I would greatly appreciate    reports    of problems with  the  documentation,
  82.      particularly  if  they are    accompanied by suggested fixes!     I promise to
  83.      back up the document sources this time  around,  so  that    disk  crashes
  84.      won't  force  me to start over from scratch (which    is what    happened this
  85.      time...).
  86.  
  87.      If    you have comments or suggestions about the documentation, contact  me
  88.      via  email     at  bdale@col.hp.com  on the Internet,    ...!winfree!bdale via
  89.      UUCP, or as 76430,3323 on Compuserve.
  90.  
  91.      My    profound thanks    to the folks who contributed to    this release, partic-
  92.      ularly Bob    Hoffman    N3CVL and Ron Henderson    WA7TAS,    without    whom it    would
  93.      have been impossible.
  94.                               Bdale    Garbee,    N3EUA
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.                       -    3 -
  137.  
  138.  
  139.      1.     Introduction to TCP/IP    and the    KA9Q Software
  140.  
  141.      This document describes the KA9Q Internet Package,    which is an implemen-
  142.      tation  of    the network protocol family originally created as part of the
  143.      Arpanet project. The protocol family is commonly refered to as "TCP/IP",
  144.      acronyms for two of the many protocols included.
  145.  
  146.      The KA9Q package is the result of several years of    development  by     Phil
  147.      Karn,  KA9Q,  and    his "merry band    of implementors". The "TCP group" has
  148.      grown to include hundreds of individuals worldwide, many  of  whom     have
  149.      contributed  ideas     and  software to this release.    All of the sources to
  150.      the software are included,    and  interested     parties  are  encouraged  to
  151.      experiment     and  contribute changes resulting from    their efforts back to
  152.      the group.    This is    discussed further in the technical appendix.
  153.  
  154.      1.1.  An Overview of the TCP/IP Protocol Family
  155.  
  156.      Following is an overview of the protocol family supported    by  the     KA9Q
  157.      package.    While reading this section will    give you a wonderful overview
  158.      of    what's going on, you can feel free to skip ahead and try out the pro-
  159.      gram  first,  then     come  back  and  read this section to flesh out your
  160.      understanding.
  161.  
  162.      1.1.1.  Acknowledgement
  163.  
  164.      The material in this section was adapted  from  a    document  written  by
  165.      Charles L.    Hedrick, of RUTGERS, The State University of New Jersey.  The
  166.      original document was Copyright 1987 by  Charles  L.  Hedrick,  and  the
  167.      material excerpted    for this section is used by permission.
  168.  
  169.      1.1.2.  Introduction
  170.  
  171.      This document is a    brief introduction to TCP/IP, followed by  advice  on
  172.      what  to  read  for more information. This     is  not  intended  to    be  a
  173.      complete  description. It    can  give  you     a  reasonable    idea  of  the
  174.      capabilities  of  the  protocols. But if you need to know any details of
  175.      the  technology, you  will     want  to  read      the    standards   yourself.
  176.      Throughout     the  text, you    will find references to    the standards, in the
  177.      form of "RFC" or "IEN" numbers. These are document     numbers.  The    final
  178.      section  of  this     document  tells  you how  to  get  copies  of    those
  179.      standards.
  180.  
  181.      1.1.3.  What is TCP/IP?
  182.  
  183.      TCP/IP  is    a set of protocols developed to    allow  cooperating  computers
  184.      to    share resources    across a network. It was developed by a     community of
  185.      researchers centered around the ARPAnet. Certainly    the  ARPAnet  is  the
  186.      best-known     TCP/IP     network. However as of    June, 87, at  least  130 dif-
  187.      ferent  vendors  had products that    support    TCP/IP,    and thousands of net-
  188.      works  of    all  kinds  use     it. Over time,    the original ARPAnet has been
  189.      phased out, and is    being replaced by a variety of networks     running  the
  190.      same protocols loosely referred to    as "The    Internet".
  191.  
  192.      First some    basic definitions. The most accurate name for  the   set   of
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.                       -    4 -
  203.  
  204.  
  205.      protocols we are describing is the    "Internet protocol suite". TCP and IP
  206.      are two of    the protocols in this  suite.    (They    will   be   described
  207.      below.)  Because  TCP and IP are the best known of    the protocols, it has
  208.      become common to use the term TCP/IP or IP/TCP  to     refer    to  the    whole
  209.      family.  It  is probably not worth    fighting this habit. However this can
  210.      lead to some oddities. For    example, I  find  myself  talking about      NFS
  211.      as     being    based  on  TCP/IP, even    though it doesn't use TCP at all. (It
  212.      does use IP. But it  uses    an  alternative     protocol,  UDP, instead   of
  213.      TCP.  All    of  this  alphabet  soup will be unscrambled in    the following
  214.      pages.)
  215.  
  216.      The Internet is a    collection  of    networks,  including   the   Arpanet,
  217.      NSFnet,  regional    networks such as NYsernet, local networks at a number
  218.      of    University and research    institutions,  and  a  number    of   military
  219.      networks.    The  term  "Internet" applies to this entire set of networks.
  220.      The subset    of them    that is    managed    by the    Department  of     Defense   is
  221.      referred    to   as     the "DDN" (Defense Data Network). This    includes some
  222.      research-oriented networks, such as  the  Arpanet,     as  well   as     more
  223.      strictly  military     ones. (Because    much of    the funding for    Internet pro-
  224.      tocol developments    is done    via   the   DDN      organization,      the    terms
  225.      Internet  and  DDN     can  sometimes     seem  equivalent.) All    of these net-
  226.      works are connected to each other.    Users can  send     messages   from  any
  227.      of     them  to  any other, except where there are security or other policy
  228.      restrictions on access. Officially     speaking,   the   Internet  protocol
  229.      documents     are   simply  standards  adopted  by  the Internet community
  230.      for its own use. More recently, the Department   of   Defense  issued  a
  231.      MILSPEC  definition  of  TCP/IP.  This  was intended to be    a more formal
  232.      definition, appropriate for use in     purchasing  specifications.  However
  233.      most  of  the  TCP/IP community continues to use the Internet standards.
  234.      The MILSPEC version is intended to    be consistent with it.
  235.  
  236.      Whatever it is called, TCP/IP is a    family of protocols.  A     few  provide
  237.      "low-level"  functions  needed  for many applications. These include IP,
  238.      TCP, and UDP. (These will be described in a bit  more   detail   later.)
  239.      Others  are  protocols for    doing specific tasks, e.g. transferring    files
  240.      between computers,    sending    mail, or finding out who is  logged   in   on
  241.      another    computer. Initially  TCP/IP  was  used    mostly    between    mini-
  242.      computers or mainframes. These machines had their own disks,   and     gen-
  243.      erally   were  self-contained.  Thus  the    most  important    "traditional"
  244.      TCP/IP services are:
  245.  
  246.     - file transfer.  The file transfer protocol (FTP) allows a user on
  247.       any computer to get files from another computer, or to send files
  248.       to another computer.    Security is handled by requiring  the  user
  249.       to  specify  a  user    name  and  password for    the other computer.
  250.       Provisions are made for handling file    transfer  between  machines
  251.       with different character set,    end of line conventions, etc.  This
  252.       is not quite the same    thing as more recent "network file  system"
  253.       or  "netbios"     protocols, which will be described below.  Rather,
  254.       FTP is a utility that    you run    any time you want to access a  file
  255.       on  another  system.      You  use  it to copy the file    to your    own
  256.       system.  You then work with the local    copy.    (See  RFC  959    for
  257.       specifications for FTP.)
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.                       -    5 -
  269.  
  270.  
  271.     - remote  login.    The    network    terminal protocol (TELNET) allows a
  272.       user to log in on any    other computer on the network.    You start a
  273.       remote session by specifying a computer to connect to.  From that
  274.       time until you finish    the session, anything you type is  sent     to
  275.       the  other  computer.      Note that you    are really still talking to
  276.       your own computer.  But the telnet program effectively makes your
  277.       computer invisible while it is running.  Every character you type
  278.       is sent directly to the other    system.     Generally, the     connection
  279.       to  the  remote  computer  behaves much like a dialup    connection.
  280.       That is, the remote system will ask you to  log  in  and  give  a
  281.       password, in whatever    manner it would    normally ask a user who    had
  282.       just dialed it up.  When you log off of the other  computer,    the
  283.       telnet  program exits, and you will find yourself talking to your
  284.       own computer.     Microcomputer implementations of telnet  generally
  285.       include  a  terminal    emulator  for some common type of terminal.
  286.       (See RFC's 854 and 855 for specifications for     telnet.    By    the
  287.       way,    the  telnet protocol should not    be confused with Telenet, a
  288.       vendor of commercial network services.)
  289.  
  290.     - computer mail.  This allows you to  send  messages  to  users     on
  291.       other     computers.    Originally, people tended to use    only one or
  292.       two specific computers.  They     would    maintain  "mail     files"     on
  293.       those    machines.  The computer    mail system is simply a    way for    you
  294.       to add a message to another user's mail file.       There  are  some
  295.       problems  with  this    in  an environment where microcomputers    are
  296.       used.     The most serious is that a micro is  not  well     suited     to
  297.       receive  computer  mail.    When you send mail, the mail software
  298.       expects to be    able  to  open    a  connection  to  the    addressee's
  299.       computer, in order to    send the mail.    If this    is a microcomputer,
  300.       it may be turned off,    or it may be running an     application  other
  301.       than    the mail system.  For this reason, mail    is normally handled
  302.       by a larger system, where it is practical to have a  mail  server
  303.       running all the time.     Microcomputer mail software then becomes a
  304.       user interface that retrieves    mail from the mail  server.    (See
  305.       RFC  821  and     822 for specifications    for computer mail.  See    RFC
  306.       937 for a protocol designed for microcomputers to use    in  reading
  307.       mail from a mail server.)
  308.  
  309.      These  services  should  be  present  in any implementation  of  TCP/IP,
  310.      except  that  micro-oriented implementations may  not  support  computer
  311.      mail. These traditional applications still    play a very important role in
  312.      TCP/IP-based  networks. However more recently,  the  way  in  which net-
  313.      works  are     used has been changing. The  older  model  of    a  number  of
  314.      large,  self-sufficient  computers     is  beginning    to  change. Now     many
  315.      installations    have    several    kinds    of    computers,    including
  316.      microcomputers, workstations, minicomputers, and  mainframes. These com-
  317.      puters  are  likely  to be     configured  to     perform  specialized  tasks.
  318.      Although  people  are still likely    to work    with one  specific  computer,
  319.      that  computer  will  call    on other systems on the    net  for  specialized
  320.      services.    This  has   led     to  the  "server/client"  model  of  network
  321.      services. A server    is a system that provides a specific service for  the
  322.      rest  of  the network. A client is    another    system    that  uses  that ser-
  323.      vice. (Note  that the server and client need not be on different comput-
  324.      ers.   They  could     be   different      programs   running   on   the     same
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.                       -    6 -
  335.  
  336.  
  337.      computer.)    Here  are  the    kinds  of  servers  typically  present    in  a
  338.      modern  computer  setup.  Note that these computer    services can  all  be
  339.      provided within the framework of TCP/IP.
  340.  
  341.     - network  file     systems.   This allows    a system to access files on
  342.       another computer in a    somewhat more  closely    integrated  fashion
  343.       than FTP.  A network file system provides the    illusion that disks
  344.       or other devices from    one system are directly    connected to  other
  345.       systems.    There  is    no need    to use a special network utility to
  346.       access a file    on another system.  Your computer simply thinks     it
  347.       has  some  extra disk    drives.     These extra "virtual" drives refer
  348.       to the other system's    disks.      This    capability  is    useful    for
  349.       several different purposes.  It lets you put large disks on a    few
  350.       computers, but still give others access to the disk space.  Aside
  351.       from the obvious economic benefits, this allows people working on
  352.       several computers  to     share    common    files.      It  makes  system
  353.       maintenance  and  backup  easier, because you    don't have to worry
  354.       about    updating  and  backing    up  copies  on    lots  of  different
  355.       machines.    A  number  of  vendors  now  offer  high-performance
  356.       diskless computers.  These computers have no disk drives at  all.
  357.       They    are  entirely dependent    upon disks attached to common "file
  358.       servers".   (See  RFC's  1001     and  1002  for     a  description     of
  359.       PC-oriented    NetBIOS      over     TCP.      In  the  workstation    and
  360.       minicomputer area, Sun's Network File    System is more likely to be
  361.       used.       Protocol  specifications  for  it are available from    Sun
  362.       Microsystems.)
  363.  
  364.     - remote printing.  This allows    you to    access    printers  on  other
  365.       computers  as    if they    were directly attached to yours.  (The most
  366.       commonly used    protocol is the    remote    lineprinter  protocol  from
  367.       Berkeley  Unix.  Unfortunately, there    is no protocol document    for
  368.       this.     However the C code is easily obtained    from  Berkeley,     so
  369.       implementations are common.)
  370.  
  371.     - remote  execution.   This allows you to request that a particular
  372.       program be run on a different    computer.  This    is useful when    you
  373.       can  do  most     of  your work on a small computer, but    a few tasks
  374.       require the resources    of a larger system.  There are a number     of
  375.       different  kinds  of remote execution.  Some operate on a command
  376.       by command basis.  That is, you request that a  specific  command
  377.       or  set  of commands should run on some specific computer.  (More
  378.       sophisticated    versions will choose a system that  happens  to     be
  379.       free.)    However  there are also "remote procedure call" systems
  380.       that allow a program to  call     a  subroutine    that  will  run     on
  381.       another  computer.    (There    are  many  protocols  of this sort.
  382.       Berkeley Unix    contains two servers to    execute    commands  remotely:
  383.       rsh  and  rexec.   The man pages describe the    protocols that they
  384.       use.    The user-contributed software with Berkeley 4.3    contains  a
  385.       "distributed    shell"    that  will  distribute tasks among a set of
  386.       systems, depending upon load.     Remote    procedure  call     mechanisms
  387.       have    been  a     topic    for research for a number of years, so many
  388.       organizations    have implementations of    such facilities.  The  most
  389.       widespread commercially-supported remote procedure call protocols
  390.       seem to be Xerox's Courier and Sun's RPC.  Protocol documents    are
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.                       -    7 -
  401.  
  402.  
  403.       available  from  Xerox and Sun.  There is a public implementation
  404.       of Courier over TCP as part of the user-contributed software with
  405.       Berkeley  4.3.   An implementation of    RPC was    posted to Usenet by
  406.       Sun, and also    appears    as part    of  the     user-contributed  software
  407.       with Berkeley    4.3.)
  408.  
  409.     - name    servers.    In    large  installations, there are    a number of
  410.       different collections    of names that have to  be  managed.    This
  411.       includes  users  and their passwords,    names and network addresses
  412.       for computers, and accounts.    It becomes  very  tedious  to  keep
  413.       this data up to date on all of the computers.     Thus the databases
  414.       are kept on a    small number of    systems.  Other    systems    access    the
  415.       data over the    network.  (RFC 822 and 823 describe the    name server
  416.       protocol used    to keep    track of host names and    Internet  addresses
  417.       on  the  Internet.    This  is  now a    required part of any TCP/IP
  418.       implementation.  IEN 116 describes an    older name server  protocol
  419.       that is used by a few    terminal servers and other products to look
  420.       up host names.  Sun's     Yellow     Pages    system    is  designed  as  a
  421.       general  mechanism to    handle user names, file    sharing    groups,    and
  422.       other    databases commonly used    by Unix     systems.    It     is  widely
  423.       available  commercially.    Its  protocol definition is available
  424.       from Sun.)
  425.  
  426.     - terminal servers.  Many installations    no longer connect terminals
  427.       directly  to    computers.    Instead they connect them    to terminal
  428.       servers.  A terminal server is simply    a small    computer that  only
  429.       knows     how  to  run  telnet  (or some    other protocol to do remote
  430.       login).  If your terminal is    connected  to  one  of    these,    you
  431.       simply  type the name    of a computer, and you are connected to    it.
  432.       Generally it is possible to have active connections to more  than
  433.       one  computer     at  the  same time.  The terminal server will have
  434.       provisions to    switch between connections rapidly, and     to  notify
  435.       you  when  output  is     waiting for another connection.  (Terminal
  436.       servers use the telnet protocol, already mentioned.  However    any
  437.       real terminal    server will also have to support name service and a
  438.       number of other protocols.)
  439.  
  440.     - network-oriented  window  systems.      Until      recently,   high-
  441.       performance  graphics     programs had to execute on a computer that
  442.       had  a  bit-mapped  graphics    screen    directly  attached  to    it.
  443.       Network  window  systems  allow  a  program to use a display on a
  444.       different computer.  Full-scale network window systems provide an
  445.       interface  that  lets    you distribute jobs to the systems that    are
  446.       best    suited    to  handle  them,  but    still  give  you  a  single
  447.       graphically-based  user  interface.  (The most widely-implemented
  448.       window system    is X. A     protocol  description    is  available  from
  449.       MIT's     Project  Athena.  A reference implementation is publically
  450.       available from MIT.  A number     of  vendors  are  also     supporting
  451.       NeWS,     a window system defined by Sun.  Both of these    systems    are
  452.       designed to use TCP/IP.)
  453.  
  454.      Note that some of the  protocols  described  above     were    designed   by
  455.      Berkeley,     Sun,    or other organizations.     Thus they are not officially
  456.      part of the Internet protocol suite.   However  they   are      implemented
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.                       -    8 -
  467.  
  468.  
  469.      using   TCP/IP,  just as normal TCP/IP application    protocols are.    Since
  470.      the protocol definitions are not  considered  proprietary,      and    since
  471.      commercially-support   implementations   are  widely  available,  it  is
  472.      reasonable    to think of these protocols as being  effectively   part   of
  473.      the   Internet   suite.   Note that the list above    is simply a sample of
  474.      the sort of services  available  through  TCP/IP.      However   it     does
  475.      contain    the   majority    of  the     "major"  applications.       The    other
  476.      commonly-used protocols tend to be    specialized facilities    for   getting
  477.      information   of    various     kinds,    such as    who is logged in, the time of
  478.      day, etc.    However    if you need a facility that is not listed  here,   we
  479.      encourage     you   to  look     through  the  current    edition     of  Internet
  480.      Protocols (currently RFC 1011),  which  lists  all     of   the   available
  481.      protocols,       and      also     to   look   at     some  of  the    major  TCP/IP
  482.      implementations to    see what various vendors have added.
  483.  
  484.      1.1.4.  General description of the    TCP/IP protocols
  485.  
  486.      TCP/IP is a layered set of    protocols.  In    order  to   understand     what
  487.      this   means,   it    is useful to look at an    example.  A typical situation
  488.      is    sending    mail.  First, there is a protocol for mail.  This  defines  a
  489.      set   of    commands which one machine sends to another, e.g. commands to
  490.      specify who the sender of the message is, who it is being sent  to,  and
  491.      then   the      text    of  the     message.  However this    protocol assumes that
  492.      there is a    way to communicate  reliably  between  the   two   computers.
  493.      Mail,   like   other  application    protocols,  simply  defines  a set of
  494.      commands and messages to be sent.    It is designed to be  used   together
  495.      with   TCP     and IP. TCP is    responsible for    making sure that the commands
  496.      get through to the    other end.  It keeps track of  what  is      sent,      and
  497.      retransmitts  anything  that did not get through.    If any message is too
  498.      large for one datagram, e.g. the text of the mail,    TCP will   split   it
  499.      up      into     several  datagrams,  and  make     sure  that  they  all arrive
  500.      correctly.     Since these functions are needed  for     many    applications,
  501.      they  are    put together into a separate protocol, rather than being part
  502.      of    the specifications for sending mail.   You  can     think    of   TCP   as
  503.      forming  a     library of routines that applications can use when they need
  504.      reliable network communications with another computer.   Similarly,  TCP
  505.      calls   on     the services of IP.  Although the services that TCP supplies
  506.      are needed    by  many  applications,     there    are  still  some   kinds   of
  507.      applications   that   don't  need them.  However there are    some services
  508.      that every    application needs.  So these services are put  together     into
  509.      IP.     As      with TCP, you    can think of IP    as a library of    routines that
  510.      TCP calls on, but which is    also available to applications     that    don't
  511.      use   TCP.        This  strategy  of building    several    levels of protocol is
  512.      called "layering".     We think of  the  applications     programs   such   as
  513.      mail,   TCP,  and IP, as being separate "layers", each of which calls on
  514.      the services of the layer below it.   Generally,    TCP/IP     applications
  515.      use 4 layers:
  516.  
  517.     - an application protocol such as mail
  518.  
  519.     - a  protocol  such  as     TCP  that  provides  services need by many
  520.       applications
  521.  
  522.     - IP, which provides the basic    service     of  getting  datagrams     to
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.                       -    9 -
  533.  
  534.  
  535.       their    destination
  536.  
  537.     - the  protocols  needed to manage a specific physical medium, such
  538.       as Ethernet or a point to point line.
  539.  
  540.      TCP/IP is based on    the "catenet model".  (This is    described   in     more
  541.      detail   in   IEN 48.)  This model    assumes    that there are a large number
  542.      of    independent networks connected together     by  gateways.       The     user
  543.      should   be  able to access computers or other resources on any of    these
  544.      networks.     Datagrams  will  often     pass  through    a   dozen   different
  545.      networks    before     getting  to  their  final  destination.  The routing
  546.      needed to accomplish this should be completely invisible to  the    user.
  547.      As      far    as  the     user  is concerned, all he needs to know in order to
  548.      access another system is an "Internet address".  This  is     an   address
  549.      that  looks  like 128.6.4.194.  It    is actually a 32-bit number.  However
  550.      it    is normally written as 4 decimal numbers, each representing  8     bits
  551.      of      the    address.  (The term "octet" is used by Internet    documentation
  552.      for such 8-bit chunks.  The term "byte" is    not used, because  TCP/IP  is
  553.      supported     by   some computers that have byte sizes other    than 8 bits.)
  554.      Generally the structure of    the  address  gives  you   some      information
  555.      about   how   to  get  to    the  system.  For example, 128.6 is a network
  556.      number assigned by    a central authority to Rutgers    University.   Rutgers
  557.      uses   the      next    octet  to  indicate  which of the campus Ethernets is
  558.      involved.    128.6.4    happens    to be an  Ethernet  used  by   the   Computer
  559.      Science   Department.     The last    octet allows for up to 254 systems on
  560.      each Ethernet.  (It is 254    because    0 and  255  are     not   allowed,      for
  561.      reasons   that   will  be    discussed  later.)  Note that 128.6.4.194 and
  562.      128.6.5.194 would be different systems.  The structure of    an   Internet
  563.      address is    described in a bit more    detail later.
  564.  
  565.      Of     course     we  normally  refer  to  systems  by  name, rather  than  by
  566.      Internet  address.      When we specify a name, the network software    looks
  567.      it     up  in     a  database,  and comes up with the  corresponding  Internet
  568.      address.    Most  of the network software deals strictly in    terms of  the
  569.      address.  (RFC 882    describes the name server technology used  to  handle
  570.      this lookup.)
  571.  
  572.      TCP/IP is    built  on  "connectionless"  technology.     Information   is
  573.      transfered      as   a sequence of "datagrams".  A datagram is a collection
  574.      of    data that is sent as a single message.    Each of    these  datagrams   is
  575.      sent   through   the network individually.     There are provisions to open
  576.      connections (i.e.    to start a conversation    that will continue  for     some
  577.      time).    However     at some level,    information from those connections is
  578.      broken up into datagrams, and  those  datagrams  are  treated   by      the
  579.      network   as   completely    separate.    For example, suppose you want to
  580.      transfer a    15000 octet file.  Most    networks can't handle a     15000    octet
  581.      datagram.      So  the protocols will break this up into something like 30
  582.      500-octet datagrams.  Each    of these datagrams  will  be  sent   to      the
  583.      other   end.     At  that point, they will    be put back together into the
  584.      15000-octet file.    However    while those datagrams are in   transit,      the
  585.      network  doesn't  know that there is any connection between them.    It is
  586.      perfectly possible     that  datagram     14  will  actually   arrive   before
  587.      datagram    13.    It is also possible that somewhere in the network, an
  588.      error will    occur, and some    datagram won't get through at all.   In     that
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.                       -    10 -
  599.  
  600.  
  601.      case, that    datagram has to    be sent    again.
  602.  
  603.      Note  by  the way that the    terms "datagram" and "packet" often  seem  to
  604.      be     nearly     interchangable.  Technically, datagram    is the right word  to
  605.      use  when    describing  TCP/IP.  A datagram    is a unit of data,  which  is
  606.      what  the    protocols deal with.  A    packet is a physical thing, appearing
  607.      on    an Ethernet or some wire.  In most cases a packet simply  contains  a
  608.      datagram,    so  there is  very  little  difference.       However  they  can
  609.      differ.  When TCP/IP is used on top of X.25, the X.25  interface  breaks
  610.      the  datagrams  up    into 128-byte packets.     This  is  invisible  to  IP,
  611.      because  the  packets  are    put back together into a single     datagram  at
  612.      the  other     end before being processed by TCP/IP.    So in this case,  one
  613.      IP     datagram  would  be carried by    several    packets.  However  with     most
  614.      media,  there  are    efficiency advantages to  sending  one    datagram  per
  615.      packet, and so the    distinction tends to vanish.
  616.  
  617.      Two separate protocols are    involved in handling TCP/IP  datagrams.      TCP
  618.      (the  "transmission  control protocol") is    responsible for     breaking  up
  619.      the  message  into     datagrams,  reassembling  them     at  the  other     end,
  620.      resending    anything  that gets lost, and  putting    things    back  in  the
  621.      right  order.  IP (the "internet protocol") is responsible     for  routing
  622.      individual     datagrams.   It may seem like TCP is  doing  all  the    work.
  623.      And  in  small networks that is true.  However in the  Internet,  simply
  624.      getting  a     datagram to its  destination  can  be    a  complex  job.    A
  625.      connection     may require the datagram to go    through    several     networks  at
  626.      Rutgers,  a  serial line to the John von Neuman Supercomputer Center,  a
  627.      couple  of    Ethernets there, a series of 56Kbaud phone lines  to  another
  628.      NSFnet  site,  and    more Ethernets on another campus.  Keeping  track  of
  629.      the  routes  to all of the    destinations and  handling  incompatibilities
  630.      among different transport media turns out to be a complex job.    Note
  631.  
  632.      that  the    interface  between TCP and IP is fairly    simple.      TCP  simply
  633.      hands  IP    a datagram with    a destination.     IP  doesn't  know  how     this
  634.      datagram relates to any datagram before it    or after it.
  635.  
  636.      It     may  have occurred to you that    something is missing here.   We     have
  637.      talked  about  Internet addresses,    but not    about how you keep  track  of
  638.      multiple  connections  to    a given    system.     Clearly it isn't  enough  to
  639.      get  a  datagram to the right  destination.    TCP     has  to  know    which
  640.      connection     this  datagram     is  part  of.    This task is referred  to  as
  641.      "demultiplexing."     In  fact, there are several levels of demultiplexing
  642.      going  on in TCP/IP.  The information needed to do     this  demultiplexing
  643.      is     contained  in a series    of "headers".  A header    is simply a few    extra
  644.      octets  tacked  onto  the    beginning of a datagram    by some     protocol  in
  645.      order  to    keep track of it.  It's    a lot like putting a letter  into  an
  646.      envelope  and  putting  an     address  on  the  outside of  the  envelope.
  647.      Except  with  modern networks it happens several times.  It's  like  you
  648.      put the letter into a little envelope, your secretary puts    that  into  a
  649.      somewhat  bigger  envelope, the campus mail center     puts  that  envelope
  650.      into a still bigger one, etc.  Here is an overview    of the    headers     that
  651.      get stuck on a message that passes    through    a typical TCP/IP network:
  652.  
  653.      We    start with a single data stream, say a file you    are trying  to     send
  654.      to    some other computer:
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.                       -    11 -
  665.  
  666.  
  667.     ......................................................
  668.  
  669.      TCP  breaks  it  up into manageable chunks.  (In order to do  this,  TCP
  670.      has  to  know how large a datagram    your network can handle.    Actually,
  671.      the TCP's at each end say how big a datagram they can handle,  and     then
  672.      they pick the smallest size.)
  673.  
  674.     ....   ....   ....   ....   ....   ....      ....     ....
  675.  
  676.      TCP puts a    header at the front of each datagram.  This  header  actually
  677.      contains    at  least 20 octets, but the most important ones are a source
  678.      and destination "port number" and    a  "sequence  number".       The     port
  679.      numbers   are  used to keep track of different conversations.  Suppose 3
  680.      different people are transferring files.  Your TCP    might  allocate     port
  681.      numbers 1000, 1001, and 1002 to these transfers.  When you    are sending a
  682.      datagram, this becomes the    "source" port number,  since  you   are      the
  683.      source   of   the    datagram.    Of     course     the TCP at the    other end has
  684.      assigned a    port number of its own for the conversation.  Your  TCP      has
  685.      to      know    the port number    used by    the other end as well.    (It finds out
  686.      when the connection starts, as we will explain below.)  It      puts     this
  687.      in      the    "destination" port field.  Of course if    the other end sends a
  688.      datagram back to you, the source and destination port numbers  will   be
  689.      reversed,     since     then  it  will     be  the  source  and you will be the
  690.      destination.  Each    datagram has a sequence    number.     This  is   used   so
  691.      that   the      other     end  can make sure that it gets the datagrams in the
  692.      right  order,  and     that  it  hasn't  missed  any.       (See       the      TCP
  693.      specification  for     details.)  TCP    doesn't    number the datagrams, but the
  694.      octets.  So if there are 500 octets of  data  in  each   datagram,      the
  695.      first  datagram  might be numbered    0, the second 500, the next 1000, the
  696.      next 1500,    etc.  Finally, I will mention the  Checksum.    This   is   a
  697.      number   that   is     computed by adding up all the octets in the datagram
  698.      (more or less - see the TCP spec).     The result is put in    the   header.
  699.      TCP   at    the other end computes the checksum again.  If they disagree,
  700.      then something bad    happened to the    datagram in transmission, and  it  is
  701.      thrown away.  So here's what the datagram looks like now.
  702.  
  703.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  704.      |        Source Port         |     Destination Port     |
  705.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  706.      |              Sequence Number             |
  707.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  708.      |              Acknowledgment Number             |
  709.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  710.      |  Data |         |U|A|P|R|S|F|                 |
  711.      | Offset| Reserved  |R|C|S|S|Y|I|          Window         |
  712.      |     |         |G|K|H|T|N|N|                 |
  713.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  714.      |         Checksum         |       Urgent Pointer     |
  715.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  716.      |   your data ... next    500 octets                 |
  717.      |   ......                             |
  718.  
  719.      If     we abbreviate the TCP header as "T", the whole    file now  looks     like
  720.      this:
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730.                       -    12 -
  731.  
  732.  
  733.     T....    T....    T....    T....    T....    T....    T....
  734.  
  735.      You will note that    there are items    in  the     header     that  I   have      not
  736.      described     above.        They  are  generally  involved  with managing the
  737.      connection.  In order to make sure    the datagram  has  arrived   at      its
  738.      destination,   the      recipient  has  to  send back    an "acknowledgement".
  739.      This is a datagram    whose "Acknowledgement number" field is     filled      in.
  740.      For   example,   sending  a  packet  with    an  acknowledgement  of     1500
  741.      indicates that you    have received all the data up to octet    number    1500.
  742.      If      the    sender    doesn't     get  an  acknowledgement within a reasonable
  743.      amount of time, it    sends the data    again.      The  window  is   used   to
  744.      control   how   much  data    can be in transit at any one time.  It is not
  745.      practical to wait for each    datagram to be acknowledged  before   sending
  746.      the   next      one.      That would slow things down too much.     On the    other
  747.      hand, you can't just keep sending,    or a fast  computer   might   overrun
  748.      the   capacity   of  a slow one to    absorb data.  Thus each    end indicates
  749.      how much new data it is currently prepared    to absorb  by    putting      the
  750.      number   of   octets  in  its  "Window" field.  As    the computer receives
  751.      data, the amount of space left in its window decreases.  When  it     goes
  752.      to      zero,     the sender has    to stop.  As the receiver processes the    data,
  753.      it    increases its window, indicating that it is ready  to    accept     more
  754.      data.   Often  the    same datagram can be used to acknowledge receipt of a
  755.      set of data and to    give permission    for  additional     new  data   (by   an
  756.      updated   window).      The "Urgent" field allows one    end to tell the    other
  757.      to    skip ahead in its processing to    a particular octet.  This  is    often
  758.      useful   for   handling asynchronous events, for example when you type a
  759.      control character or other    command    that interrupts    output.      The    other
  760.      fields are    beyond the scope of this document.
  761.  
  762.      1.1.5.  The IP level
  763.  
  764.      TCP  sends    each of    these datagrams    to IP.    Of course it has to  tell  IP
  765.      the  Internet  address of the computer at the other end.  Note that this
  766.      is     all  IP  is concerned about.  It doesn't care about what is  in  the
  767.      datagram,    or  even in the    TCP header.  IP's job is  simply  to  find  a
  768.      route for the datagram and    get it to the other end.  In order  to    allow
  769.      gateways  or  other intermediate systems to  forward  the    datagram,  it
  770.      adds  its    own  header.  The main things in this header are  the  source
  771.      and  destination  Internet    address    (32-bit    addresses, like    128.6.4.194),
  772.      the  protocol  number,  and  another  checksum.    The  source  Internet
  773.      address  is  simply the address of    your machine.  (This is    necessary  so
  774.      the  other     end  knows where the datagram came from.)   The  destination
  775.      Internet  address    is the address    of  the     other    machine.    (This  is
  776.      necessary    so  any     gateways  in  the  middle  know where you  want  the
  777.      datagram  to  go.)     The protocol number tells IP at  the  other  end  to
  778.      send  the    datagram  to TCP.  Although most IP traffic uses  TCP,    there
  779.      are  other     protocols that    can use    IP, so you  have  to  tell  IP    which
  780.      protocol  to send the datagram to.     Finally, the checksum allows  IP  at
  781.      the  other     end to    verify that the    header    wasn't    damaged     in  transit.
  782.      Note  that    TCP and    IP have    separate checksums.  IP    needs to be  able  to
  783.      verify that the header didn't get damaged in transit, or it could send a
  784.      message to    the wrong place.  For reasons not worth    discussing  here,  it
  785.      is     both  more  efficient    and  safer to have  TCP     compute  a  separate
  786.      checksum  for  the     TCP  header  and  data.  Once IP has tacked  on  its
  787.  
  788.  
  789.  
  790.  
  791.  
  792.  
  793.  
  794.  
  795.  
  796.                       -    13 -
  797.  
  798.  
  799.      header, here's what the message looks like:
  800.  
  801.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  802.      |Version|  IHL     |Type of Service|        Total Length     |
  803.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  804.      |       Identification     |Flags|      Fragment Offset     |
  805.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  806.      |  Time to Live |    Protocol     |       Header Checksum     |
  807.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  808.      |             Source    Address                 |
  809.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  810.      |              Destination Address             |
  811.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  812.      |  TCP    header,    then your data ......                 |
  813.      |                                 |
  814.  
  815.      If    we represent the IP header by an "I",  your  file  now     looks     like
  816.      this:
  817.  
  818.     IT....     IT....      IT....   IT....   IT....   IT....   IT....
  819.  
  820.      Again,  the  header contains some additional fields that have  not     been
  821.      discussed.      Most    of them    are beyond the scope of    this document.      The
  822.      flags  and    fragment offset    are used to keep track of the pieces  when  a
  823.      datagram  has  to be split    up.   This  can     happen     when  datagrams  are
  824.      forwarded through a network for which they    are too    big.  (This  will  be
  825.      discussed    a  bit more below.)  The time to live is  a  number  that  is
  826.      decremented  whenever  the     datagram passes through a system.   When  it
  827.      goes  to  zero, the datagram is discarded.     This is done in case a     loop
  828.      develops  in the system somehow.  Of course this should  be  impossible,
  829.      but   well-designed   networks  are  built     to  cope  with     "impossible"
  830.      conditions.
  831.  
  832.      At    this point, it's possible that no more headers are needed.   If     your
  833.      computer  happens    to have    a direct phone    line  connecting  it  to  the
  834.      destination  computer,  or     to  a    gateway,  it  may  simply   send  the
  835.      datagrams    out  on    the line (though likely    a synchronous  protocol     such
  836.      as     HDLC  would be    used, and it would add at least    a few octets  at  the
  837.      beginning and end).
  838.  
  839.      1.1.6.  The Ethernet level
  840.  
  841.      However most of our networks these    days use Ethernet.  So now  we     have
  842.      to      describe   Ethernet's    headers.  Unfortunately, Ethernet has its own
  843.      addresses.     The people who    designed Ethernet wanted to make  sure     that
  844.      no      two    machines  would     end  up  with    the  same  Ethernet  address.
  845.      Furthermore, they    didn't    want  the  user     to  have  to    worry    about
  846.      assigning     addresses.    So  each  Ethernet  controller    comes with an
  847.      address builtin from the factory.    In order to  make  sure      that     they
  848.      would   never  have to reuse addresses, the Ethernet designers allocated
  849.      48    bits for the Ethernet address.    People who make     Ethernet   equipment
  850.      have   to     register  with     a  central  authority,    to make    sure that the
  851.      numbers they assign don't overlap any other manufacturer.    Ethernet is a
  852.      "broadcast     medium".   That  is,  it is in    effect like an old party line
  853.  
  854.  
  855.  
  856.  
  857.  
  858.  
  859.  
  860.  
  861.  
  862.                       -    14 -
  863.  
  864.  
  865.      telephone.     When you send a packet    out on the Ethernet,  every   machine
  866.      on      the    network    sees the packet.  So something is needed to make sure
  867.      that the right machine gets it.  As you might guess, this    involves  the
  868.      Ethernet    header.        Every  Ethernet packet has a 14-octet header that
  869.      includes the source and destination Ethernet address, and a  type    code.
  870.      Each  machine  is supposed    to pay attention only to packets with its own
  871.      Ethernet address in the destination field.     (It's     perfectly   possible
  872.      to      cheat,   which  is  one reason that Ethernet communications are not
  873.      terribly secure.)    Note  that  there  is  no  connection    between      the
  874.      Ethernet  address    and the    Internet address.  Each    machine    has to have a
  875.      table of what Ethernet address corresponds    to what      Internet   address.
  876.      (We   will      describe  how     this  table is    constructed a bit later.)  In
  877.      addition to the addresses,    the header contains a type code.   The     type
  878.      code  is  to allow    for several different protocol families    to be used on
  879.      the same network.    So you can use TCP/IP, DECnet, Xerox  NS,   etc.   at
  880.      the   same      time.      Each of them will put    a different value in the type
  881.      field.  Finally,  there  is  a  checksum.      The    Ethernet   controller
  882.      computes  a  checksum of the entire packet.  When the other end receives
  883.      the packet, it recomputes the checksum, and throws    the packet  away   if
  884.      the   answer   disagrees  with the    original.  The checksum    is put on the
  885.      end of the    packet,    not in the header.  The    final result is      that     your
  886.      message looks like    this:
  887.  
  888.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  889.      |     Ethernet destination address (first 32    bits)         |
  890.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  891.      | Ethernet dest (last 16 bits)     |Ethernet source (first 16 bits)|
  892.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  893.      |     Ethernet source address (last 32 bits)             |
  894.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  895.      |      Type code         |
  896.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  897.      |  IP header, then TCP    header,    then your data             |
  898.      |                                 |
  899.          ...
  900.      |                                 |
  901.      |   end of your data                         |
  902.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  903.      |             Ethernet Checksum             |
  904.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  905.  
  906.      If     we  represent    the  Ethernet  header  with  "E",  and    the  Ethernet
  907.      checksum with "C",    your file now looks like this:
  908.  
  909.     EIT....C   EIT....C   EIT....C     EIT....C   EIT....C
  910.  
  911.      When these    packets    are received by    the other end, of  course   all      the
  912.      headers   are   removed.     The  Ethernet interface removes the Ethernet
  913.      header and    the checksum.  It looks    at the type code.  Since   the     type
  914.      code   is    the one    assigned to IP,    the Ethernet device driver passes the
  915.      datagram up to IP.     IP removes the    IP header.   It     looks    at   the   IP
  916.      protocol    field.       Since  the  protocol     type  is  TCP,    it passes the
  917.      datagram up to TCP.  TCP now looks    at the sequence    number.        It     uses
  918.      the   sequence   numbers  and  other  information    to  combine  all  the
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.                       -    15 -
  929.  
  930.  
  931.      datagrams into the    original file.
  932.  
  933.      The ends our initial summary of TCP/IP.  There are    still  some   crucial
  934.      concepts  we  haven't gotten to, so we'll now go back and add details in
  935.      several areas.  (For detailed descriptions    of the items  discussed     here
  936.      see,   RFC      793  for  TCP,  RFC  791  for    IP, and    RFC's 894 and 826 for
  937.      sending IP    over Ethernet.)
  938.  
  939.      1.1.7.  Well-known    sockets    and the    applications layer
  940.  
  941.      So    far, we    have described how a stream  of     data  is  broken   up     into
  942.      datagrams,      sent     to another computer, and put back together.  However
  943.      something more is needed  in  order  to  accomplish   anything   useful.
  944.      There   has   to  be  a  way for you to open a connection to a specified
  945.      computer, log into    it, tell it what file you  want,  and    control      the
  946.      transmission   of     the  file.   (If you have a different application in
  947.      mind, e.g.    computer mail, some analogous protocol is needed.)   This  is
  948.      done   by     "application  protocols".  The    application protocols run "on
  949.      top" of TCP/IP.  That is, when they want to send a    message,  they     give
  950.      the   message   to     TCP.    TCP makes sure it gets delivered to the    other
  951.      end.  Because TCP and IP take care    of all the networking  details,      the
  952.      applications   protocols  can treat a network connection as if it were a
  953.      simple byte stream, like a    terminal or phone line.
  954.  
  955.      Before going into more details about applications programs, we  have  to
  956.      describe  how  you    find an    application.  Suppose you want to send a file
  957.      to    a computer whose Internet address  is  128.6.4.7.    To      start      the
  958.      process,    you   need  more than just the Internet    address.  You have to
  959.      connect to    the FTP    server at the  other  end.    In   general,   network
  960.      programs    are   specialized  for a specific set of tasks.     Most systems
  961.      have separate programs  to     handle     file  transfers,   remote   terminal
  962.      logins,  mail,  etc.  When    you connect to 128.6.4.7, you have to specify
  963.      that you want to talk to the FTP server.     This  is  done      by   having
  964.      "well-known   sockets"   for  each     server.    Recall that    TCP uses port
  965.      numbers to    keep track of  individual  conversations.     User   programs
  966.      normally    use  more or less random port numbers.    However    specific port
  967.      numbers are assigned to the programs that sit  waiting   for   requests.
  968.      For   example,   if  you  want  to    send a file, you will start a program
  969.      called "ftp".  It will open a connection using some random     number,  say
  970.      1234,   for   the    port number on its end.     However it will specify port
  971.      number 21 for the other end.  This    is the official    port number  for  the
  972.      FTP  server.   Note that there are    two different programs involved.  You
  973.      run ftp on    your side.  This is a program designed to   accept   commands
  974.      from   your   terminal  and  pass them on to the other end.  The program
  975.      that you talk to on the other machine  is    the  FTP  server.     It   is
  976.      designed    to   accept commands from the network connection, rather than
  977.      an    interactive terminal.  There is    no need    for your program to   use   a
  978.      well-known      socket   number  for    itself.     Nobody    is trying to find it.
  979.      However the servers have to have well-known numbers,  so    that   people
  980.      can   open      connections  to  them    and start sending them commands.  The
  981.      official  port  numbers  for  each     program  are  given   in   "Assigned
  982.      Numbers".
  983.  
  984.      Note  that     a  connection is actually described by    a set of  4  numbers:
  985.  
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993.  
  994.                       -    16 -
  995.  
  996.  
  997.      the  Internet  address at each end, and the TCP port number at each end.
  998.      Every  datagram  has  all    four of    those numbers in it.   (The  Internet
  999.      addresses    are  in    the IP header, and the TCP port    numbers     are  in  the
  1000.      TCP header.)  In order to keep things straight, no    two  connections  can
  1001.      have  the    same set of numbers.  However it is enough for any one number
  1002.      to     be  different.       For    example,  it  is perfectly possible  for  two
  1003.      different    users  on a machine to be sending files     to  the  same    other
  1004.      machine.     This  could  result  in  connections  with   the   following
  1005.      parameters:
  1006.  
  1007.             Internet addresses       TCP ports
  1008.      connection 1  128.6.4.194, 128.6.4.7       1234, 21
  1009.      connection 2  128.6.4.194, 128.6.4.7       1235, 21
  1010.  
  1011.      Since the same machines are involved, the Internet    addresses   are      the
  1012.      same.     Since   they  are  both    doing  file transfers, one end of the
  1013.      connection    involves the well-known    port number  for  FTP.       The     only
  1014.      thing   that   differs is the port    number for the program that the    users
  1015.      are running.  That's enough of a difference.  Generally, at  least      one
  1016.      end   of    the  connection    asks the network software to assign it a port
  1017.      number that is guaranteed to be unique.   Normally,  it's     the   user's
  1018.      end, since    the server has to use a    well-known number.
  1019.  
  1020.      Now  that    we  know  how  to  open     connections, let's get    back  to  the
  1021.      applications  programs.   As mentioned earlier, once TCP  has  opened  a
  1022.      connection,  we  have  something  that might as well be a    simple    wire.
  1023.      All  the  hard parts are handled by TCP and IP.  However we  still     need
  1024.      some  agreement  as  to  what we send over    this connection.   In  effect
  1025.      this  is  simply an agreement on what set of  commands  the  application
  1026.      will  understand,    and  the  format  in  which  they  are    to  be    sent.
  1027.      Generally,     what  is sent is a combination    of commands and    data.     They
  1028.      use  context  to  differentiate.  For example, the    mail  protocol    works
  1029.      like  this:  Your mail program opens a connection to the mail server  at
  1030.      the  other    end.  Your program gives it your machine's name,  the  sender
  1031.      of    the message, and the recipients    you want it sent to.  It then sends a
  1032.      command saying that it is starting    the  message.    At  that  point,  the
  1033.      other  end      stops     treating  what     it  sees  as  commands,  and  starts
  1034.      accepting    the  message.  Your end    then starts sending the    text  of  the
  1035.      message.    At  the    end of the message, a special mark is sent (a dot  in
  1036.      the first column).     After that, both ends understand that    your  program
  1037.      is     again    sending    commands.  This    is the simplest    way to do things, and
  1038.      the one that most applications use.
  1039.  
  1040.      File  transfer  is     somewhat more complex.     The file  transfer  protocol
  1041.      involves  two  different connections.  It starts  out  just  like    mail.
  1042.      The user's    program    sends commands like "log me in as this    user",    "here
  1043.      is     my  password",    "send me the file with this name".  However once  the
  1044.      command  to  send    data is    sent, a    second connection is opened  for  the
  1045.      data  itself.   It    would certainly    be possible to send the    data  on  the
  1046.      same  connection,    as  mail does.    However    file transfers often  take  a
  1047.      long  time.   The designers of the     file  transfer     protocol  wanted  to
  1048.      allow  the     user  to  continue  issuing commands while the     transfer  is
  1049.      going  on.      For example, the user    might make an inquiry,    or  he    might
  1050.      abort  the     transfer.    Thus  the    designers felt it was best to  use  a
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.                       -    17 -
  1061.  
  1062.  
  1063.      separate  connection  for    the  data  and    leave  the  original  command
  1064.      connection     for  commands.       (It    is  also  possible  to    open  command
  1065.      connections  to  two different computers, and tell    them to    send  a     file
  1066.      from  one    to  the    other.    In that    case, the data couldn't    go  over  the
  1067.      command connection.)
  1068.  
  1069.      Remote terminal connections use another mechanism still.     For   remote
  1070.      logins,   there   is just one connection.    It normally sends data.     When
  1071.      it    is necessary to    send a command (e.g. to    set the    terminal type  or  to
  1072.      change   some   mode),  a special character is used to indicate that the
  1073.      next character is a command.  If the user happens to type    that  special
  1074.      character as data,    two of them are    sent.
  1075.  
  1076.      We     are  not  going to describe the application protocols in  detail  in
  1077.      this  document.   It's better to read the RFC's yourself.    However    there
  1078.      are  a  couple of common conventions used by applications that  will  be
  1079.      described    here.    First, the common network representation:  TCP/IP  is
  1080.      intended  to  be  usable  on  any    computer.    Unfortunately,  not  all
  1081.      computers    agree  on how data is represented.  There are differences  in
  1082.      character    codes  (ASCII  vs.  EBCDIC),  in  end  of   line  conventions
  1083.      (carriage    return,     line feed, or a representation    using counts), and in
  1084.      whether  terminals    expect characters to be    sent individually or  a     line
  1085.      at     a  time.   In    order  to  allow  computers  of     different  kinds  to
  1086.      communicate,   each   applications      protocol   defines    a    standard
  1087.      representation.     Note    that  TCP  and    IP  do    not  care  about  the
  1088.      representation.    TCP  simply  sends octets.  However the     programs  at
  1089.      both  ends     have to agree on how the octets are to    be interpreted.      The
  1090.      RFC  for  each  application  specifies the    standard  representation  for
  1091.      that  application.      Normally it  is  "net     ASCII".    This  uses    ASCII
  1092.      characters,  with end of line denoted by a    carriage return    followed by a
  1093.      line  feed.   For    remote    login,    there  is  also     a  definition    of  a
  1094.      "standard terminal", which    turns out to be    a half-duplex  terminal     with
  1095.      echoing  happening     on the    local machine.    Most applications  also     make
  1096.      provisions     for  the  two    computers to agree on  other  representations
  1097.      that  they     may find more convenient.  For    example, PDP-10's have 36-bit
  1098.      words.    There  is a way that two    PDP-10's can agree to send  a  36-bit
  1099.      binary  file.   Similarly,    two systems that prefer    full-duplex  terminal
  1100.      conversations  can     agree    on  that.    However each application  has  a
  1101.      standard representation, which every machine must support.
  1102.  
  1103.      1.1.8.  An    example    application: SMTP
  1104.  
  1105.      In    order to give a    bit better idea    what is    involved in  the  application
  1106.      protocols,      I'm    going  to  show    an example of SMTP, which is the mail
  1107.      protocol.    (SMTP is "simple mail transfer protocol.)  We assume  that  a
  1108.      computer called TOPAZ.RUTGERS.EDU wants to    send the following message.
  1109.  
  1110.        Date: Sat, 27 Jun 87 13:26:31 EDT
  1111.        From: hedrick@topaz.rutgers.edu
  1112.        To: levy@red.rutgers.edu
  1113.        Subject:    meeting
  1114.  
  1115.        Let's get together Monday at 1pm.
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122.  
  1123.  
  1124.  
  1125.  
  1126.                       -    18 -
  1127.  
  1128.  
  1129.      First,  note  that    the format of the message itself is described  by  an
  1130.      Internet  standard     (RFC 822).  The standard specifies the    fact that the
  1131.      message  must be transmitted as net ASCII (i.e. it    must be     ASCII,     with
  1132.      carriage  return/linefeed    to delimit lines).   It     also  describes  the
  1133.      general  structure, as a group of header lines, then a blank  line,  and
  1134.      then  the    body of    the message.  Finally, it describes the    syntax of the
  1135.      header  lines in detail.  Generally they consist of a keyword and then a
  1136.      value.
  1137.  
  1138.      Note  that     the  addressee     is  indicated      as    LEVY@RED.RUTGERS.EDU.
  1139.      Initially,      addresses  were simply "person at machine".  However recent
  1140.      standards have made things    more flexible.    There  are   now   provisions
  1141.      for   systems   to    handle other systems' mail.  This can allow automatic
  1142.      forwarding    on behalf of computers not connected to    the  Internet.       It
  1143.      can  be  used to direct mail for a    number of systems to one central mail
  1144.      server.  Indeed there is no requirement that an actual computer  by  the
  1145.      name   of    RED.RUTGERS.EDU    even exist.  The name servers could be set up
  1146.      so    that you mail to department names, and each  department's   mail   is
  1147.      routed   automatically  to    an appropriate computer.  It is    also possible
  1148.      that the part before the @    is something other than    a user name.   It  is
  1149.      possible    for   programs    to be set up to    process    mail.  There are also
  1150.      provisions     to  handle  mailing  lists,  and  generic  names   such   as
  1151.      "postmaster" or "operator".
  1152.  
  1153.      The  way  the  message is to be sent to another system is    described  by
  1154.      RFC's  821     and 974.  The program that is going to    be doing the  sending
  1155.      asks  the    name server several queries to determine where to  route  the
  1156.      message.    The  first query is to find out    which  machines     handle     mail
  1157.      for  the  name RED.RUTGERS.EDU.  In this case, the    server    replies     that
  1158.      RED.RUTGERS.EDU  handles  its own mail.  The program then asks  for  the
  1159.      address of    RED.RUTGERS.EDU, which is 128.6.4.2.  Then the    mail  program
  1160.      opens  a  TCP connection to port 25  on  128.6.4.2.    Port  25  is  the
  1161.      well-known     socket     used  for receiving mail.  Once this  connection  is
  1162.      established,  the    mail program starts sending  commands.      Here    is  a
  1163.      typical  conversation.  Each line is labelled as to whether it  is     from
  1164.      TOPAZ or RED.  Note that TOPAZ initiated the connection:
  1165.  
  1166.           RED    220 RED.RUTGERS.EDU SMTP Service at 29 Jun     87  05:17:18
  1167.       EDT
  1168.           TOPAZ  HELO topaz.rutgers.edu
  1169.           RED    250 RED.RUTGERS.EDU - Hello, TOPAZ.RUTGERS.EDU
  1170.           TOPAZ  MAIL From:<hedrick@topaz.rutgers.edu>
  1171.           RED    250 MAIL accepted
  1172.           TOPAZ  RCPT To:<levy@red.rutgers.edu>
  1173.           RED    250 Recipient accepted
  1174.           TOPAZ  DATA
  1175.           RED    354 Start mail input; end with <CRLF>.<CRLF>
  1176.           TOPAZ  Date: Sat,    27 Jun 87 13:26:31 EDT
  1177.           TOPAZ  From: hedrick@topaz.rutgers.edu
  1178.           TOPAZ  To: levy@red.rutgers.edu
  1179.           TOPAZ  Subject: meeting
  1180.           TOPAZ
  1181.           TOPAZ  Let's get together    Monday at 1pm.
  1182.           TOPAZ  .
  1183.  
  1184.  
  1185.  
  1186.  
  1187.  
  1188.  
  1189.  
  1190.  
  1191.  
  1192.                       -    19 -
  1193.  
  1194.  
  1195.           RED    250 OK
  1196.           TOPAZ  QUIT
  1197.           RED    221 RED.RUTGERS.EDU Service closing transmission channel
  1198.  
  1199.      First, note that commands all use normal text.  This is typical  of  the
  1200.      Internet    standards.     Many  of     the  protocols     use  standard    ASCII
  1201.      commands.    This makes it easy  to    watch  what  is     going    on   and   to
  1202.      diagnose    problems.   For    example, the mail program keeps    a log of each
  1203.      conversation.  If something goes wrong, the log  file  can      simply   be
  1204.      mailed   to   the    postmaster.  Since it is normal    text, he can see what
  1205.      was going on.  It also allows a human to interact    directly   with      the
  1206.      mail   server,   for  testing.  (Some newer protocols are complex enough
  1207.      that this is not practical.  The commands would have to have  a   syntax
  1208.      that  would  require a significant    parser.     Thus there is a tendency for
  1209.      newer protocols to    use binary formats.  Generally they  are   structured
  1210.      like   C  or Pascal record    structures.)  Second, note that    the responses
  1211.      all begin with numbers.  This is also typical of    Internet   protocols.
  1212.      The   allowable   responses  are  defined    in the protocol.  The numbers
  1213.      allow the user program to respond unambiguously.     The  rest   of      the
  1214.      response    is   text,  which is normally for use by any human who may be
  1215.      watching or looking at a log.  It has no effect on     the   operation   of
  1216.      the   programs.   (However    there is one point at which the    protocol uses
  1217.      part of the text of the response.)      The  commands      themselves   simply
  1218.      allow   the   mail     program  on  one  end    to  tell  the mail server the
  1219.      information it needs to know in order to deliver the message.   In     this
  1220.      case,   the   mail     server     could    get the    information by looking at the
  1221.      message itself.  But for more complex cases, that would not   be    safe.
  1222.      Every   session   must  begin  with  a HELO, which    gives the name of the
  1223.      system that initiated the connection.  Then the sender  and   recipients
  1224.      are  specified.   (There can be more than one RCPT    command, if there are
  1225.      several recipients.)  Finally the data itself is sent.  Note  that      the
  1226.      text   of    the message is terminated by a line containing just a period.
  1227.      (If such a    line appears in    the message, the period    is  doubled.)    After
  1228.      the   message   is     accepted,  the     sender     can send another message, or
  1229.      terminate the session as in the example above.
  1230.  
  1231.      Generally,    there is a pattern to the response numbers.    The   protocol
  1232.      defines   the   specific set of responses that can    be sent    as answers to
  1233.      any given command.     However programs that don't want to   analyze     them
  1234.      in      detail   can    just  look at the first    digit.    In general, responses
  1235.      that begin    with a 2  indicate  success.    Those  that  begin   with   3
  1236.      indicate    that  some further action is needed, as    shown above.  4    and 5
  1237.      indicate errors.  4 is a "temporary" error, such as  a   disk   filling.
  1238.      The   message  should be saved, and tried again later.  5 is a permanent
  1239.      error, such as a  non-existent  recipient.       The    message      should   be
  1240.      returned to the sender with an error message.
  1241.  
  1242.      (For  more     details about the protocols mentioned in this    section,  see
  1243.      RFC's  821/822  for mail, RFC 959 for file    transfer, and  RFC's  854/855
  1244.      for  remote  logins.  For the well-known port numbers, see     the  current
  1245.      edition of    Assigned Numbers, and possibly RFC 814.)
  1246.  
  1247.  
  1248.  
  1249.  
  1250.  
  1251.  
  1252.  
  1253.  
  1254.  
  1255.  
  1256.  
  1257.  
  1258.                       -    20 -
  1259.  
  1260.  
  1261.      1.2.  Protocols other than    TCP: UDP and ICMP
  1262.  
  1263.      So    far, we    have described only connections    that use TCP.    Recall     that
  1264.      TCP   is    responsible  for  breaking  up    messages  into datagrams, and
  1265.      reassembling them properly.  However in  many  applications,   we     have
  1266.      messages    that   will  always  fit in a single datagram.    An example is
  1267.      name lookup.  When    a user attempts    to make     a  connection     to   another
  1268.      system,   he   will  generally  specify  the system by name, rather than
  1269.      Internet address.    His system has to translate that name to  an  address
  1270.      before   it   can    do  anything.  Generally, only a few systems have the
  1271.      database used to translate    names to addresses.  So    the   user's   system
  1272.      will  want     to send a query to one    of the systems that has    the database.
  1273.      This query    is going to be very short.  It will certainly  fit   in      one
  1274.      datagram.       So    will the answer.  Thus it seems    silly to use TCP.  Of
  1275.      course TCP    does more than just break things up  into   datagrams.       It
  1276.      also   makes   sure  that    the  data  arrives, resending datagrams    where
  1277.      necessary.     But for a question that fits  in  a  single   datagram,   we
  1278.      don't   need   all    the complexity of TCP to do this.  If we don't get an
  1279.      answer after a few    seconds, we can    just ask again.       For     applications
  1280.      like this,    there are alternatives to TCP.
  1281.  
  1282.      The most common alternative is UDP    ("user datagram    protocol").   UDP  is
  1283.      designed  for  applications where you don't need  to  put    sequences  of
  1284.      datagrams    together.  It fits into    the system much    like TCP.  There is a
  1285.      UDP  header.  The network software    puts the UDP header on    the  front of
  1286.      your  data, just as it would put a    TCP header on the front    of your    data.
  1287.      Then  UDP sends the data  to  IP,    which  adds  the  IP  header, putting
  1288.      UDP's  protocol number in the protocol field instead of  TCP's  protocol
  1289.      number.   However    UDP  doesn't do    as much     as  TCP  does.       It doesn't
  1290.      split data    into multiple datagrams.  It doesn't keep track     of  what  it
  1291.      has  sent so it can resend    if necessary.  About  all  that     UDP provides
  1292.      is     port  numbers,     so  that several programs can use UDP at once.      UDP
  1293.      port  numbers  are    used just like TCP port     numbers.    There are    well-
  1294.      known  port numbers for servers that use UDP.  Note that the UDP  header
  1295.      is     shorter than a    TCP header.   It  still     has  source  and destination
  1296.      port  numbers,  and  a checksum,  but  that's  about  it.     No  sequence
  1297.      number, since it is not needed.  UDP is used by the protocols that     han-
  1298.      dle  name    lookups    (see IEN 116, RFC 882, and RFC 883), and a number  of
  1299.      similar protocols.
  1300.  
  1301.      Another  alternative  protocol  is     ICMP  ("Internet   control   message
  1302.      protocol").     ICMP   is    used  for  error messages, and other messages
  1303.      intended for the TCP/IP software itself, rather  than   any   particular
  1304.      user   program.   For example, if you attempt to connect to a host, your
  1305.      system may    get back an ICMP message saying    "host  unreachable".     ICMP
  1306.      can   also     be used to find out some information about the    network.  See
  1307.      RFC 792 for details of ICMP.  ICMP    is  similar  to     UDP,  in   that   it
  1308.      handles  messages    that fit in one    datagram.  However it is even simpler
  1309.      than UDP.    It doesn't even    have port numbers in its header.   Since  all
  1310.      ICMP   messages  are interpreted by the network software itself, no port
  1311.      numbers are needed    to say where a ICMP message is supposed    to go.
  1312.  
  1313.  
  1314.  
  1315.  
  1316.  
  1317.  
  1318.  
  1319.  
  1320.  
  1321.  
  1322.  
  1323.  
  1324.                       -    21 -
  1325.  
  1326.  
  1327.      1.3.  Keeping track of names and information: the domain system
  1328.  
  1329.      As    we indicated earlier, the network software generally needs  a  32-bit
  1330.      Internet    address      in  order  to    open a connection or send a datagram.
  1331.      However users prefer to deal with computer    names rather  than   numbers.
  1332.      Thus   there   is    a database that    allows the software to look up a name
  1333.      and find the corresponding    number.     When the Internet was    small,     this
  1334.      was   easy.   Each    system would have a file that listed all of the    other
  1335.      systems, giving both their    name and number.  There    are  now   too     many
  1336.      computers     for   this  approach to be practical.    Thus these files have
  1337.      been replaced by a    set of name servers that keep track of     host    names
  1338.      and   the    corresponding Internet addresses.  (In fact these servers are
  1339.      somewhat more general than    that.  This is just one    kind  of  information
  1340.      stored  in     the domain system.)  Note that    a set of interlocking servers
  1341.      are used, rather than a single central one.  There     are  now   so     many
  1342.      different     institutions    connected  to  the  Internet that it would be
  1343.      impractical for them to  notify  a     central  authority   whenever     they
  1344.      installed     or  moved a computer.    Thus naming authority is delegated to
  1345.      individual    institutions.  The name    servers    form a    tree,    corresponding
  1346.      to      institutional      structure.    The names themselves follow a similar
  1347.      structure.     A typical example is the name BORAX.LCS.MIT.EDU.  This     is a
  1348.      computer    at   the  Laboratory  for  Computer Science (LCS) at MIT.  In
  1349.      order to find its Internet    address,  you  might  potentially   have   to
  1350.      consult   4   different  servers.    First, you would ask a central server
  1351.      (called the root) where the EDU server is.     EDU is    a server  that    keeps
  1352.      track  of    educational institutions.  The root server would give you the
  1353.      names and Internet    addresses of several servers for EDU.     (There      are
  1354.      several   servers     at  each  level,  to allow for    the possibly that one
  1355.      might be down.)  You would    then ask EDU where the server for   MIT      is.
  1356.      Again,   it   would  give    you  names  and    Internet addresses of several
  1357.      servers for MIT.  Generally, not all of those servers would be  at     MIT,
  1358.      to      allow     for the possibility of    a general power    failure    at MIT.     Then
  1359.      you would ask MIT where the server    for LCS    is, and    finally      you    would
  1360.      ask  one  of the LCS servers about    BORAX.    The final result would be the
  1361.      Internet address for BORAX.LCS.MIT.EDU.    Each  of  these      levels   is
  1362.      referred    to   as     a  "domain".  The entire name,    BORAX.LCS.MIT.EDU, is
  1363.      called a "domain name".    (So  are  the  names  of   the     higher-level
  1364.      domains, such as LCS.MIT.EDU, MIT.EDU, and    EDU.)
  1365.  
  1366.      Fortunately,  you    don't really have to go    through    all of this  most  of
  1367.      the  time.      First    of all,    the root name servers also happen to  be  the
  1368.      name  servers  for     the  top-level    domains    such as    EDU.  Thus  a  single
  1369.      query  to    a root    server    will  get  you    to  MIT.    Second,  software
  1370.      generally    remembers answers that it got before.  So once we look    up  a
  1371.      name  at  LCS.MIT.EDU, our    software remembers where to find servers  for
  1372.      LCS.MIT.EDU,  MIT.EDU,  and EDU.  It also remembers the  translation  of
  1373.      BORAX.LCS.MIT.EDU.      Each    of these pieces    of information has a "time to
  1374.      live"  associated with it.     Typically this    is a few days.     After    that,
  1375.      the  information  expires and has to be looked up again.     This  allows
  1376.      institutions to change things.
  1377.  
  1378.      The  domain  system  is not limited to finding out     Internet  addresses.
  1379.      Each  domain  name    is a node in a database.  The node can    have  records
  1380.      that  define  a number of different properties.  Examples    are  Internet
  1381.  
  1382.  
  1383.  
  1384.  
  1385.  
  1386.  
  1387.  
  1388.  
  1389.  
  1390.                       -    22 -
  1391.  
  1392.  
  1393.      address,  computer     type, and a list of services provided by a computer.
  1394.      A    program     can  ask  for    a  specific  piece  of    information,  or  all
  1395.      information  about     a given name.    It is possible    for  a    node  in  the
  1396.      database  to  be  marked as an "alias" (or    nickname) for  another    node.
  1397.      It     is  also possible to use the  domain  system  to  store  information
  1398.      about users, mailing lists, or other objects.
  1399.  
  1400.      There  is    an  Internet  standard    defining  the  operation   of    these
  1401.      databases,     as  well as the protocols used     to  make  queries  of    them.
  1402.      Every  network utility has    to be able to make such    queries,  since     this
  1403.      is     now  the official way to evaluate host    names.     Generally  utilities
  1404.      will talk to a server on their own    system.     This server will  take     care
  1405.      of     contacting  the other servers for them.  This keeps down the  amount
  1406.      of    code that has to be in each application    program.
  1407.  
  1408.      The  domain  system  is  particularly  important for  handling  computer
  1409.      mail.  There are entry types to define what computer handles mail    for a
  1410.      given  name, to specify where an individual is to receive mail,  and  to
  1411.      define mailing lists.
  1412.  
  1413.      (See RFC's    882, 883, and 973 for specifications of    the  domain   system.
  1414.      RFC 974 defines the use of    the domain system in sending mail.)
  1415.  
  1416.      1.4.  Routing
  1417.  
  1418.      The   description    above  indicated  that    the  IP      implementation   is
  1419.      responsible  for  getting datagrams to the    destination indicated by  the
  1420.      destination address, but little was said about how    this would  be    done.
  1421.      The  task    of finding how to  get    a  datagram  to     its  destination  is
  1422.      referred to as "routing".    In fact    many of    the details depend  upon  the
  1423.      particular    implementation.     However some general things can be said.
  1424.  
  1425.      First, it is necessary to understand the model on which IP      is   based.
  1426.      IP     assumes  that a system    is attached to some local network.  We assume
  1427.      that the system can send datagrams    to any    other  system  on   its      own
  1428.      network.      (In    the  case  of  Ethernet, it simply finds the Ethernet
  1429.      address of    the destination    system,    and puts the datagram  out   on      the
  1430.      Ethernet.)        The      problem  comes  when    a  system  is asked to send a
  1431.      datagram to a system on a different network.  This    problem     is   handled
  1432.      by      gateways.    A gateway is a system that connects a network with one
  1433.      or    more other networks.  Gateways    are  often  normal   computers     that
  1434.      happen  to    have more than one network interface.  For example, we have a
  1435.      Unix machine that has two different Ethernet  interfaces.     Thus  it  is
  1436.      connected     to  networks 128.6.4 and 128.6.3.  This machine can act as a
  1437.      gateway between those two networks.  The software on that    machine     must
  1438.      be      set    up  so that it will forward datagrams from one network to the
  1439.      other.  That is, if a machine on network 128.6.4 sends a    datagram   to
  1440.      the   gateway,   and  the    datagram is addressed to a machine on network
  1441.      128.6.3, the gateway will forward the  datagram  to   the     destination.
  1442.      Major  communications  centers often have gateways    that connect a number
  1443.      of    different  networks.    (In  many  cases,   special-purpose   gateway
  1444.      systems  provide  better performance or reliability than general-purpose
  1445.      systems acting as gateways.  A number of vendors sell such    systems.)
  1446.  
  1447.  
  1448.  
  1449.  
  1450.  
  1451.  
  1452.  
  1453.  
  1454.  
  1455.  
  1456.                       -    23 -
  1457.  
  1458.  
  1459.      Routing in    IP is  based  entirely    upon  the  network  number   of      the
  1460.      destination   address.    Each computer has a table of network numbers.
  1461.      For each network number, a    gateway    is listed.  This is the     gateway   to
  1462.      be     used  to get to that network.    Note that the gateway doesn't have to
  1463.      connect directly to the network.  It just has to be the best  place   to
  1464.      go      to   get there.  For example at Rutgers, our interface to NSFnet is
  1465.      at    the John von Neuman Supercomputer Center (JvNC). Our  connection   to
  1466.      JvNC   is     via  a     high-speed  serial line connected to a    gateway    whose
  1467.      address is    128.6.3.12.  Systems on    net 128.6.3 will list  128.6.3.12  as
  1468.      the   gateway   for  many    off-campus  networks.  However systems on net
  1469.      128.6.4 will list 128.6.4.1 as the    gateway    to  those   same   off-campus
  1470.      networks.       128.6.4.1   is  the    gateway     between networks 128.6.4 and
  1471.      128.6.3, so it is the first step in getting to JvNC.
  1472.  
  1473.      When a computer wants to send a datagram, it first    checks    to   see   if
  1474.      the   destination    address    is on the system's own local network.  If so,
  1475.      the datagram can be sent directly.     Otherwise, the    system     expects   to
  1476.      find  an  entry for the network that the destination address is on.  The
  1477.      datagram is sent to the gateway listed in that entry.  This  table      can
  1478.      get  quite     big.  For example, the    Internet now includes several hundred
  1479.      individual    networks.  Thus    various    strategies have    been   developed   to
  1480.      reduce   the  size    of the routing table.  One strategy is to depend upon
  1481.      "default routes".    Often, there is    only one gateway out of     a   network.
  1482.      This   gateway  might connect a local Ethernet to a campus-wide backbone
  1483.      network.  In that case, we    don't need to have  a  separate      entry      for
  1484.      every   network   in  the    world.      We  simply define that gateway as a
  1485.      "default".     When no specific  route  is  found  for  a   datagram,      the
  1486.      datagram    is   sent to the default gateway.  A default gateway can even
  1487.      be    used when there    are several gateways  on  a  network.      There      are
  1488.      provisions      for    gateways  to  send a message saying "I'm not the best
  1489.      gateway --    use this one instead."    (The message is    sent via  ICMP.      See
  1490.      RFC   792.)   Most    network    software is designed to    use these messages to
  1491.      add entries to their routing tables.  Suppose network 128.6.4  has      two
  1492.      gateways,    128.6.4.59  and    128.6.4.1.  128.6.4.59 leads to    several    other
  1493.      internal Rutgers networks.     128.6.4.1 leads indirectly to    the   NSFnet.
  1494.      Suppose   we   set     128.6.4.59  as     a default gateway, and    have no    other
  1495.      routing table entries.  Now what  happens    when  we  need    to   send   a
  1496.      datagram    to   MIT?    MIT  is  network 18.  Since we have no entry for
  1497.      network 18, the datagram will be sent to the default,  128.6.4.59.       As
  1498.      it      happens,   this  gateway  is the wrong one.  So it will forward the
  1499.      datagram to 128.6.4.1.  But it will also send back    an error  saying   in
  1500.      effect:  "to  get to network 18, use 128.6.4.1".  Our software will then
  1501.      add an entry to the routing table.     Any future datagrams to   MIT     will
  1502.      then   go     directly to 128.6.4.1.     (The error message is sent using the
  1503.      ICMP protocol.  The message type is called    "ICMP redirect.")
  1504.  
  1505.      Most IP experts recommend that individual computers should    not  try   to
  1506.      keep   track   of    the  entire network.  Instead, they should start with
  1507.      default gateways, and let the gateways tell them the routes,   as     just
  1508.      described.       However  this doesn't say how the gateways should find out
  1509.      about the routes.    The gateways can't depend upon this  strategy.     They
  1510.      have   to     have fairly complete routing tables.  For this, some sort of
  1511.      routing protocol is needed.  A routing protocol is    simply    a   technique
  1512.      for   the     gateways  to  find each other,    and keep up to date about the
  1513.  
  1514.  
  1515.  
  1516.  
  1517.  
  1518.  
  1519.  
  1520.  
  1521.  
  1522.                       -    24 -
  1523.  
  1524.  
  1525.      best way to get to    every network.     RFC  1009  contains  a      review   of
  1526.      gateway   design    and  routing.     However rip.doc is probably a better
  1527.      introduction to the subject.  It contains some tutorial material,    and a
  1528.      detailed description of the most commonly-used routing protocol.
  1529.  
  1530.      1.5.  Details about Internet addresses: subnets and broadcasting
  1531.  
  1532.      As     indicated earlier, Internet addresses are 32-bit  numbers,  normally
  1533.      written as    4 octets (in decimal), e.g. 128.6.4.7.    There are  actually 3
  1534.      different types of    address.  The problem is  that    the  address  has  to
  1535.      indicate  both  the network and the host within the  network.    It  was
  1536.      felt  that     eventually  there would be lots of networks.  Many  of     them
  1537.      would  be    small, but probably 24 bits would be needed to represent  all
  1538.      the  IP  networks.     It was    also felt that some very big  networks    might
  1539.      need  24  bits to represent all of    their hosts.  This would seem to lead
  1540.      to     48  bit  addresses.  But the designers    really wanted to use  32  bit
  1541.      addresses.      So  they adopted a kludge.  The assumption is    that most  of
  1542.      the  networks will    be small.  So they set up three    different  ranges  of
  1543.      address.    Addresses  beginning with 1 to 126 use only the     first    octet
  1544.      for  the network number.  The other three octets are available  for  the
  1545.      host  number.   Thus 24 bits are available    for hosts.  These numbers are
  1546.      used  for large networks.    But there can only be 126 of these  very  big
  1547.      networks.     The  Arpanet is one, and there    are a  few  large  commercial
  1548.      networks.      But  few  normal organizations get one of these  "class  A"
  1549.      addresses.      For  normal large organizations, "class  B"  addresses  are
  1550.      used.    Class  B    addresses  use the first two octets for     the  network
  1551.      number.   Thus  network numbers are 128.1 through 191.254.     (We avoid  0
  1552.      and  255,    for  reasons  that  we    see below.  We also  avoid  addresses
  1553.      beginning    with  127, because that    is used    by some    systems     for  special
  1554.      purposes.)       The    last  two  octets  are available for  host  addesses,
  1555.      giving  16     bits of host address.     This  allows  for  64516  computers,
  1556.      which should be enough for    most organizations.  (It is possible  to  get
  1557.      more  than     one class B address, if you run  out.)       Finally,  class  C
  1558.      addresses    use  three  octets,  in     the  range 192.1.1  to     223.254.254.
  1559.      These  allow  only    254 hosts on each network, but there can be  lots  of
  1560.      these  networks.    Addresses above    223 are    reserved for future  use,  as
  1561.      class D and E (which are currently    not defined).
  1562.  
  1563.      Many large    organizations find it convenient to  divide   their   network
  1564.      number into "subnets".  For example, Rutgers has been assigned a class B
  1565.      address, 128.6.  We find it convenient to use the    third  octet  of  the
  1566.      address  to  indicate which Ethernet a host is on.     This division has no
  1567.      significance outside of Rutgers.  A computer  at    another      institution
  1568.      would  treat  all datagrams addressed to 128.6 the    same way.  They    would
  1569.      not look at the third octet of the    address.   Thus      computers   outside
  1570.      Rutgers   would   not have    different routes for 128.6.4 or    128.6.5.  But
  1571.      inside Rutgers, we    treat 128.6.4 and 128.6.5 as separate  networks.   In
  1572.      effect,  gateways    inside Rutgers have separate entries for each Rutgers
  1573.      subnet, whereas gateways outside  Rutgers    just  have  one      entry      for
  1574.      128.6.   Note   that  we  could  do  exactly  the    same thing by using a
  1575.      separate class C address for each Ethernet.   As  far  as     Rutgers   is
  1576.      concerned,      it   would be    just as    convenient for us to have a number of
  1577.      class C addresses.     However using class C addresses would    make   things
  1578.      inconvenient  for    the rest of the    world.    Every institution that wanted
  1579.  
  1580.  
  1581.  
  1582.  
  1583.  
  1584.  
  1585.  
  1586.  
  1587.  
  1588.                       -    25 -
  1589.  
  1590.  
  1591.      to    talk to    us would have to have a    separate entry for each    one  of      our
  1592.      networks.      If  every institution    did this, there    would be far too many
  1593.      networks for any reasonable gateway to keep track of.  By    subdividing a
  1594.      class  B network, we hide our internal structure from everyone else, and
  1595.      save  them     trouble.    This  subnet  strategy  requires  special provi-
  1596.      sions in the network software.  It    is described in    RFC 950.
  1597.  
  1598.      0    and  255  have    special     meanings.  0 is reserved for  machines     that
  1599.      don't know    their address.    In certain circumstances it is possible    for a
  1600.      machine not to know the number of the network it is on, or    even its  own
  1601.      host  address.   For  example, 0.0.0.23 would be a    machine    that  knew it
  1602.      was host number 23, but didn't know on what network.
  1603.  
  1604.      255  is  used for "broadcast".  A broadcast is a message that  you     want
  1605.      every  system  on the network to see.    Broadcasts  are  used  in     some
  1606.      situations     where you don't know who to talk to.  For  example,  suppose
  1607.      you  need    to look     up  a    host  name  and     get  its  Internet  address.
  1608.      Sometimes    you  don't know    the address of the nearest name     server.   In
  1609.      that  case,  you might send the request as    a broadcast.  There are     also
  1610.      cases  where a number of systems are interested in    information.   It  is
  1611.      then  less     expensive to send a single broadcast than to send  datagrams
  1612.      individually  to  each host that is interested in the  information.   In
  1613.      order  to    send a broadcast, you use an address that is  made  by    using
  1614.      your  network  address, with all ones in the part of the  address    where
  1615.      the  host    number goes.  For example, if you are on network 128.6.4, you
  1616.      would   use   128.6.4.255    for  broadcasts.    How     this    is   actually
  1617.      implemented  depends  upon    the medium.   It  is  not  possible  to     send
  1618.      broadcasts     on the    Arpanet, or on point to    point lines.  However  it  is
  1619.      possible  on  an Ethernet.     If you    use an Ethernet    address    with all  its
  1620.      bits  on (all ones), every    machine    on the Ethernet    is supposed  to     look
  1621.      at    that datagram.
  1622.  
  1623.      Although the official broadcast address for  network  128.6.4   is      now
  1624.      128.6.4.255,   there   are     some  other addresses that may    be treated as
  1625.      broadcasts    by certain implementations.  For convenience,  the   standard
  1626.      also   allows   255.255.255.255 to    be used.  This refers to all hosts on
  1627.      the local network.     It is often simpler to    use  255.255.255.255  instead
  1628.      of      finding  out the network number for the local    network    and forming a
  1629.      broadcast address such as 128.6.4.255.   In  addition,   certain    older
  1630.      implementations   may   use  0  instead  of  255  to  form    the broadcast
  1631.      address.     Such  implementations    would  use  128.6.4.0    instead       of
  1632.      128.6.4.255   as    the  broadcast    address    on network 128.6.4.  Finally,
  1633.      certain older implementations may not understand about  subnets.     Thus
  1634.      they  consider  the network number    to be 128.6.  In that case, they will
  1635.      assume a broadcast    address     of  128.6.255.255  or     128.6.0.0.    Until
  1636.      support   for   broadcasts    is implemented properly, it can    be a somewhat
  1637.      dangerous feature to use.
  1638.  
  1639.      Because 0 and 255 are used    for unknown and    broadcast  addresses,  normal
  1640.      hosts   should  never be given addresses containing 0 or 255.  Addresses
  1641.      should never begin    with 0,    127, or    any number above   223.        Addresses
  1642.      violating    these  rules are sometimes referred to as "Martians", because
  1643.      of    rumors that the    Central    University of Mars is using network 225.
  1644.  
  1645.  
  1646.  
  1647.  
  1648.  
  1649.  
  1650.  
  1651.  
  1652.  
  1653.  
  1654.                       -    26 -
  1655.  
  1656.  
  1657.      1.6.  Datagram fragmentation and reassembly
  1658.  
  1659.      TCP/IP is designed    for use     with  many  different    kinds    of   network.
  1660.      Unfortunately,   network    designers  do not agree    about how big packets
  1661.      can be.  Ethernet packets can be 1500 octets long.        Arpanet   packets
  1662.      have   a    maximum     of around 1000    octets.     Some very fast    networks have
  1663.      much larger packet    sizes.    At first, you might think  that      IP   should
  1664.      simply   settle   on  the    smallest  possible size.  Unfortunately, this
  1665.      would cause serious performance problems.      When     transferring    large
  1666.      files,  big  packets are far more efficient than small ones.  So we want
  1667.      to    be able    to use the largest packet size possible.  But we  also     want
  1668.      to      be   able  to     handle     networks  with     small limits.    There are two
  1669.      provisions    for this.  First, TCP has the ability to  "negotiate"    about
  1670.      datagram    size.    When a TCP connection first opens, both    ends can send
  1671.      the maximum datagram size they can     handle.    The     smaller   of    these
  1672.      numbers   is   used  for  the  rest  of the connection.  This allows two
  1673.      implementations that can handle big datagrams to use  them,   but     also
  1674.      lets   them   talk     to  implementations that can't    handle them.  However
  1675.      this doesn't completely solve the problem.     The most   serious   problem
  1676.      is      that    the two    ends don't necessarily know about all of the steps in
  1677.      between.  For example, when sending data between Rutgers  and  Berkeley,
  1678.      it     is  likely that both computers    will be    on Ethernets.  Thus they will
  1679.      both  be  prepared     to  handle  1500-octet     datagrams.    However      the
  1680.      connection     will  at some point end up going over the Arpanet.  It    can't
  1681.      handle packets of that size.  For this reason, there are  provisions  to
  1682.      split    datagrams       up    into   pieces.      (This     is  referred  to  as
  1683.      "fragmentation".)    The IP header  contains     fields     indicating   the   a
  1684.      datagram    has   been split, and enough information to let    the pieces be
  1685.      put back together.     If a gateway connects an Ethernet to  the   Arpanet,
  1686.      it     must  be prepared to take 1500-octet Ethernet packets and split them
  1687.      into pieces that will fit on the Arpanet.      Furthermore,     every     host
  1688.      implementation   of   TCP/IP  must     be prepared to    accept pieces and put
  1689.      them back together.  This is referred to as "reassembly".
  1690.  
  1691.      TCP/IP implementations differ in the approach they    take to     deciding  on
  1692.      datagram    size.      It  is  fairly  common  for  implementations to use
  1693.      576-byte datagrams    whenever they can't verify that    the entire  path   is
  1694.      able   to     handle    larger packets.     This rather conservative strategy is
  1695.      used because of the number    of implementations with    bugs in    the  code  to
  1696.      reassemble      fragments.     Implementors  often try to avoid ever having
  1697.      fragmentation occur.  Different implementors take    different  approaches
  1698.      to      deciding   when  it  is safe to use large datagrams.    Some use them
  1699.      only for the local    network.  Others will use them for any     network   on
  1700.      the    same    campus.    576  bytes  is  a  "safe"  size,     which    every
  1701.      implementation must support.
  1702.  
  1703.      1.7.  Ethernet encapsulation: ARP
  1704.  
  1705.      There was a brief discussion earlier about    what IP    datagrams  look     like
  1706.      on      an   Ethernet.    The     discussion  showed  the  Ethernet header and
  1707.      checksum.    However    it left    one hole: It didn't say    how to     figure      out
  1708.      what  Ethernet  address to    use when you want to talk to a given Internet
  1709.      address.  In fact,    there is a separate protocol for this,     called      ARP
  1710.      ("address     resolution  protocol").  (Note    by the way that    ARP is not an
  1711.  
  1712.  
  1713.  
  1714.  
  1715.  
  1716.  
  1717.  
  1718.  
  1719.  
  1720.                       -    27 -
  1721.  
  1722.  
  1723.      IP    protocol.  That    is, the    ARP datagrams  do  not    have   IP   headers.)
  1724.      Suppose   you   are  on  system  128.6.4.194  and you want    to connect to
  1725.      system 128.6.4.7.    Your system will first verify that 128.6.4.7  is   on
  1726.      the   same     network, so it    can talk directly via Ethernet.     Then it will
  1727.      look up 128.6.4.7 in its ARP table, to see    if  it    already      knows      the
  1728.      Ethernet    address.     If     so, it    will stick on an Ethernet header, and
  1729.      send the packet.  But suppose this    system is not  in  the     ARP   table.
  1730.      There   is      no  way  to  send the    packet,    because    you need the Ethernet
  1731.      address.  So it  uses  the     ARP  protocol    to  send  an   ARP   request.
  1732.      Essentially   an    ARP  request  says  "I    need the Ethernet address for
  1733.      128.6.4.7".  Every    system listens to ARP requests.     When a     system     sees
  1734.      an      ARP    request     for itself, it    is required to respond.     So 128.6.4.7
  1735.      will see the request, and will respond with an  ARP  reply      saying   in
  1736.      effect  "128.6.4.7     is 8:0:20:1:56:34".  (Recall that Ethernet addresses
  1737.      are 48 bits.  This    is 6 octets.  Ethernet addresses  are  conventionally
  1738.      shown   in      hex,    using  the punctuation shown.)    Your system will save
  1739.      this information in its ARP table,    so future packets will    go  directly.
  1740.      Most   systems   treat the    ARP table as a cache, and clear    entries    in it
  1741.      if    they have not been used    in a certain period of time.
  1742.  
  1743.      Note by the way that ARP requests must be sent as    "broadcasts".    There
  1744.      is      no   way  that  an  ARP  request  can    be sent    directly to the    right
  1745.      system.  After all, the whole reason for sending  an  ARP     request   is
  1746.      that   you      don't    know the Ethernet address.  So an Ethernet address of
  1747.      all ones is  used,     i.e.  ff:ff:ff:ff:ff:ff.    By      convention,    every
  1748.      machine   on   the    Ethernet is required to    pay attention to packets with
  1749.      this as an    address.  So every system sees every ARP   requests.     They
  1750.      all   look     to see    whether    the request is for their own address.  If so,
  1751.      they respond.  If not, they could just ignore it.     (Some     hosts     will
  1752.      use   ARP     requests  to update their knowledge about other hosts on the
  1753.      network, even if the request isn't    for them.)  Note that  packets    whose
  1754.      IP      address   indicates broadcast    (e.g. 255.255.255.255 or 128.6.4.255)
  1755.      are also sent with    an Ethernet address that is all    ones.
  1756.  
  1757.      1.8.  Getting more    information
  1758.  
  1759.      This directory contains  documents     describing  the   major   protocols.
  1760.      There   are  literally hundreds of    documents, so we have chosen the ones
  1761.      that seem most important.    Internet standards are called  RFC's.      RFC
  1762.      stands   for   Request  for  Comment.   A proposed    standard is initially
  1763.      issued as a proposal, and given an    RFC number.   When  it     is   finally
  1764.      accepted,     it  is    added to Official Internet Protocols, but it is    still
  1765.      referred to by the    RFC number.   We  have    also  included     two   IEN's.
  1766.      (IEN's   used   to     be  a    separate  classification  for  more  informal
  1767.      documents.     This classification no    longer exists -- RFC's are  now     used
  1768.      for   all     official  Internet documents, and a mailing list is used for
  1769.      more informal reports.)  The convention is    that  whenever    an   RFC   is
  1770.      revised,  the  revised version gets a new number.    This is    fine for most
  1771.      purposes, but it causes problems with two documents:  Assigned   Numbers
  1772.      and   Official   Internet    Protocols.  These documents are    being revised
  1773.      all the time, so the RFC number keeps changing.  You will have  to     look
  1774.      in     rfc-index.txt    to find    the number of the latest edition.  Anyone who
  1775.      is    seriously interested in    TCP/IP should read the    RFC   describing   IP
  1776.      (791).    RFC  1009 is also useful.  It is a specification for gateways
  1777.  
  1778.  
  1779.  
  1780.  
  1781.  
  1782.  
  1783.  
  1784.  
  1785.  
  1786.                       -    28 -
  1787.  
  1788.  
  1789.      to    be used    by NSFnet.  As such, it    contains an overview of     a   lot   of
  1790.      the   TCP/IP  technology.    You should probably also read the description
  1791.      of    at least one of    the application    protocols, just    to get a   feel      for
  1792.      the   way     things     work.      Mail is probably a good one (821/822).  TCP
  1793.      (793) is of course    a very basic specification.  However  the   spec   is
  1794.      fairly   complex,     so  you should    only read this when you    have the time
  1795.      and patience to think about it carefully.    Fortunately, the  author   of
  1796.      the   major   RFC's  (Jon Postel) is a very good writer.  The TCP RFC is
  1797.      far easier    to read    than you would expect, given the complexity  of     what
  1798.      it      is   describing.    You  can    look at    the other RFC's    as you become
  1799.      curious about their subject matter.
  1800.  
  1801.      Here is a list of the documents you are more likely to want:
  1802.  
  1803.       rfc-index list of all    RFC's
  1804.  
  1805.       rfc1012   somewhat fuller list of all    RFC's
  1806.  
  1807.       rfc1011   Official Protocols.     It's useful to    scan  this  to    see
  1808.             what tasks protocols have been built for.  This defines
  1809.             which  RFC's  are  actual  standards,  as  opposed     to
  1810.             requests for comments.
  1811.  
  1812.       rfc1010   Assigned  Numbers.    If you are working with    TCP/IP,    you
  1813.             will probably want a hardcopy of this as  a     reference.
  1814.             It's  not  very  exciting  to  read.   It lists all    the
  1815.             offically defined well-known ports and  lots  of  other
  1816.             things.
  1817.  
  1818.       rfc1009   NSFnet  gateway  specifications.  A    good overview of IP
  1819.             routing and    gateway    technology.
  1820.  
  1821.       rfc1001/2 netBIOS: networking    for PC's
  1822.  
  1823.       rfc973    update on domains
  1824.  
  1825.       rfc959    FTP    (file transfer)
  1826.  
  1827.       rfc950    subnets
  1828.  
  1829.       rfc937    POP2: protocol for reading mail on PC's
  1830.  
  1831.       rfc894    how    IP is to be put    on Ethernet, see also rfc825
  1832.  
  1833.       rfc882/3  domains (the database used to go  from  host  names     to
  1834.             Internet  address  and back    -- also    used to    handle UUCP
  1835.             these days).  See also rfc973
  1836.  
  1837.       rfc854/5  telnet - protocol for remote logins
  1838.  
  1839.       rfc826    ARP    - protocol for finding out Ethernet addresses
  1840.  
  1841.       rfc821/2  mail
  1842.  
  1843.  
  1844.  
  1845.  
  1846.  
  1847.  
  1848.  
  1849.  
  1850.  
  1851.  
  1852.                       -    29 -
  1853.  
  1854.  
  1855.       rfc814    names and ports - general  concepts     behind     well-known
  1856.             ports
  1857.  
  1858.       rfc793    TCP
  1859.  
  1860.       rfc792    ICMP
  1861.  
  1862.       rfc791    IP
  1863.  
  1864.       rfc768    UDP
  1865.  
  1866.       rip.doc   details of the most    commonly-used routing protocol
  1867.  
  1868.       ien-116   old     name  server  (still  needed  by  several kinds of
  1869.             system)
  1870.  
  1871.       ien-48    the     Catenet  model,   general   description   of    the
  1872.             philosophy behind TCP/IP
  1873.  
  1874.      The following documents are somewhat more specialized.
  1875.  
  1876.       rfc813    window and acknowledgement strategies in TCP
  1877.  
  1878.       rfc815    datagram reassembly    techniques
  1879.  
  1880.       rfc816    fault isolation and    resolution techniques
  1881.  
  1882.       rfc817    modularity and efficiency in implementation
  1883.  
  1884.       rfc879    the    maximum    segment    size option in TCP
  1885.  
  1886.       rfc896    congestion control
  1887.  
  1888.       rfc827,888,904,975,985
  1889.             EGP    and related issues
  1890.  
  1891.      To    those of you who may be    reading    this document remotely     instead   of
  1892.      at      Rutgers:   The  most    important  RFC's  have    been collected into a
  1893.      three-volume set, the DDN Protocol    Handbook.  It is available  from  the
  1894.      DDN   Network   Information  Center,  SRI    International, 333 Ravenswood
  1895.      Avenue, Menlo Park, California 94025 (telephone:  800-235-3155).      You
  1896.      should  be    able to    get them via anonymous FTP from    sri-nic.arpa.
  1897.  
  1898.      rip.doc is    available  by  anonymous  FTP  from   topaz.rutgers.edu,   as
  1899.      /pub/tcp-ip-docs/rip.doc.
  1900.  
  1901.      IBM PC 360k floppies with ARC'ed versions of the  RFC's  and  IEN's  are
  1902.      also available from the TAPR office, thanks to Andy Freeborn, N0CCZ.
  1903.  
  1904.      1.9.  Overview of the KA9Q    Internet Package
  1905.  
  1906.      The software associated with this document    represents the culmination of
  1907.      what might    be described as    a first    phase of implementaton.     The emphasis
  1908.      to    date has been on building a robust platform on which  to  build     real
  1909.  
  1910.  
  1911.  
  1912.  
  1913.  
  1914.  
  1915.  
  1916.  
  1917.  
  1918.                       -    30 -
  1919.  
  1920.  
  1921.      networks.     To this end, the core protocols have been extensively tested
  1922.      and verified.  In addition, great emphasis    has been placed    on increasing
  1923.      the  portability  of  the    software,  supporting  more and    more hardware
  1924.      interfaces, and making it possible    to use as many    networking  technolo-
  1925.      gies (asynch or RS-232 lines, Ethernet, various packet radio interfaces,
  1926.      digipeaters, NET/ROM, etc)    as possible.
  1927.  
  1928.      The down side is that the user interface can be  described     at  best  as
  1929.      "terse".    The good news is that many individuals are working on improv-
  1930.      ing the interface,    and great strides have been  made  in  the  Macintosh
  1931.      implementation.   In the meantime,    we ask only that you realize what our
  1932.      priorities    have been, and understand that even the     implementors  aren't
  1933.      always proud of "how it looks".
  1934.  
  1935.      This release provides support for the IP, ICMP, TCP, UDP, FTP, SMTP, and
  1936.      Telnet  protocols from the    basic Arpanet set.  In addition, the ARP pro-
  1937.      tocol is available    for address resolution on AX.25    and  Ethernet  inter-
  1938.      faces,  and  support  is provided for NET/ROM used    as a transport.    It is
  1939.      unfortunately necessary, as a result of the ongoing  NET/ROM  vs  TheNet
  1940.      debate,  to mention that the NET/ROM implementation included here is the
  1941.      original work of Dan Frank, W9NK, working    solely    from  documents     pub-
  1942.      lished by Software    2000.
  1943.  
  1944.      This release includes sources that    are known to compile and run well  on
  1945.      PC     clones    using MS-Dos, several flavors of System    V Unix,    including HP-
  1946.      UX    and Microport on AT clones, the    HP Portable Plus, the Atari  ST,  and
  1947.      the NEC PC-9801.
  1948.  
  1949.      Binaries are available on floppy for the PC and clones as part  of     this
  1950.      release.  Floppies     are  available     for the Mactintosh version, which is
  1951.      maintained    separately but in parallel with    the mainstream release.
  1952.  
  1953.      Other machines for    which code is provided that may    or may not  (probably
  1954.      not) work include the Amiga and BSD Unix.
  1955.  
  1956.  
  1957.  
  1958.  
  1959.  
  1960.  
  1961.  
  1962.  
  1963.  
  1964.  
  1965.  
  1966.  
  1967.  
  1968.  
  1969.  
  1970.  
  1971.  
  1972.  
  1973.  
  1974.  
  1975.  
  1976.  
  1977.  
  1978.  
  1979.  
  1980.  
  1981.  
  1982.  
  1983.  
  1984.                       -    31 -
  1985.  
  1986.  
  1987.      2.     Installation
  1988.  
  1989.  
  1990.      2.1.  What    an IP Address Is, and How to Get One
  1991.  
  1992.      IP    Addresses are 32 bit numbers that uniquely identify a  given  machine
  1993.      (or  "host")  running  the    TCP/IP protocol    suite. All of the possible 32
  1994.      bit numbers are coordinated by an entity known as the  Network  Informa-
  1995.      tion  Center,  or    NIC.  Amateur Radio operators are fortunate in that a
  1996.      "Class A Subnet"  consisting  of  24  bits     of  address,  in  the    range
  1997.      44.X.X.X,    has  been  reserved  for our use. By general concensus,    Brian
  1998.      Kantor, WB6CYT, of    San Diego, CA, now serves as the top  level  adminis-
  1999.      trator of the 44.X.X.X address space, and assigns blocks of addresses to
  2000.      regional coordinators from    around the world.
  2001.  
  2002.      You need to have a    unique address before you can link in with  the     rest
  2003.      of     the  networked     world.     The best way to get one is to ask around the
  2004.      local packet community and    find out who your local     address  coordinator
  2005.      is.  Your    local  coordinator  will  then assign you an address from the
  2006.      block for your area.
  2007.  
  2008.      Brian Kantor can be reached as brian@ucsd.edu on  the  Internet  if  you
  2009.      need help locating    your local address coordinator.
  2010.  
  2011.      2.2.  Configuring a TNC for TCP/IP    Operation
  2012.  
  2013.      This section describes the     procedure  for     configuring  various  packet
  2014.      radio Terminal Node Controller units (TNC's) for operation    with the KA9Q
  2015.      package.  Readers who will    be using the package with only SLIP or Ether-
  2016.      net (wired) connections can feel free to skip ahead to section 2.2.
  2017.  
  2018.      There are now several choices for TNCs to be  used      with     the   TCP/IP
  2019.      network  code.  Versions  of  the    Keep  It  Simple Stupid    TNC interface
  2020.      software (KISS) are available for the TNC-1, the TNC-2, the VADCG    board
  2021.      and   clones  (Ashby),  the Kantronics  family  of     TNCs,    and  the  AEA
  2022.      TNCs. Following are the different setup/configuration modes for the dif-
  2023.      ferent TNCs.
  2024.  
  2025.      2.2.1.  TAPR TNC-1    and Clones
  2026.  
  2027.      The firmware for the TNC-1    is available in    either a downloadable version
  2028.      or      a  stand  alone  version.   I     will  describe     only the stand    alone
  2029.      version here.  Locate the ROM labeled E000    and remove  it.      Insert  the
  2030.      KISS  PROM     in  its  place    making    sure  that you orient the prom in the
  2031.      same direction (failure to    do so will result in smoked  PROM).   Connect
  2032.      your  TNC-1  to   your   computer    using  an RS-232 cable.     A cable that
  2033.      passes the    signals    from pins 2, 3,    and 7 is suffi-    cient.
  2034.  
  2035.      Since the TNC-1 has no switches for setting the baud rate    to  the     com-
  2036.      puter   the  firmware has been "hard wired" to 4800 baud.    See the    docu-
  2037.      mentation that comes with the TNC-1 version of KISS for instructions  on
  2038.      how to patch the .HEX  file for other baud    rates.
  2039.  
  2040.      There is also a newer  version  of     the  TNC-1  KISS  firmware  that  is
  2041.  
  2042.  
  2043.  
  2044.  
  2045.  
  2046.  
  2047.  
  2048.  
  2049.  
  2050.                       -    32 -
  2051.  
  2052.  
  2053.      documented    in the TNC_TNC1.ARC file in the    distribution.
  2054.  
  2055.      TAPR can provide programmed TNC-1 KISS EPROMs.
  2056.  
  2057.      2.2.2.  TAPR TNC-2    and Clones
  2058.  
  2059.      The  standard firmware for    the TNC-2 now supports a  'KISS'  command  to
  2060.      turn  on  KISS support.  If you wish to use the KISS command included in
  2061.      1.1.6 firmware, read your TNC documentation for more info.
  2062.  
  2063.      If    you want to run    KISS only, or have an older TNC-2  without  the     KISS
  2064.      command,  dig out the TNC_TNC2.ARC    package    and read the docs included on
  2065.      how to program an EPROM with the firmware (or buy a ROM from TAPR),  and
  2066.      then proceed.
  2067.  
  2068.      Open up your TNC and locate the ROM.  It is in the    socket labeled "U23."
  2069.      Using  a    small    nail  file  or screwdriver gently pry up the existing
  2070.      EPROM. Carefully press the    new EPROM into    place  being  sure  that  the
  2071.      orientation   is  the  same.  If  you  are     installing  the 2764 type of
  2072.      EPROM you will need to make a small modification to the TNC.  There is a
  2073.      location  on  the    board  just  above  the    first RAM socket labeled JMP-
  2074.      6.     Turn the board    over and cut the trace joining the two pads.   Solder
  2075.      a    two-pin     jumper     header     in  place.    When  using  a  type 2764  the
  2076.      jumper  at     JMP-6 should be removed and  installed     when  a  type    27256
  2077.      EPROM  is    being  used.   That  should complete the hardware part of the
  2078.      installa- tion.  As an alternative    you may    choose to burn the KISS     code
  2079.      into a 27256 and not bother with jumpers.
  2080.  
  2081.      Attach your TNC to    your PC    using an RS-232C cable.     You can use the same
  2082.      cable  that  you  were using to connect your PC to    your TNC.  If you are
  2083.      doing this    for the    first time and are not sure  about  your  cabling,  a
  2084.      cable  with  just    pins  2, 3, and    7 passed through is sufficient.     Some
  2085.      PCs like to see the signals Clear To Send (CTS, pin 5), Data  Set    Ready
  2086.      (DSR,  pin    6),  and  Data    Carrier     Detect    (DCD,  pin  8) asserted.  You
  2087.      can set this up by    jumpering pin 4    to 5, and pin 20 to pins 6 and    8  at
  2088.      the female    DB-25 connector    that goes to the PC.
  2089.  
  2090.      Now to verify that    the TNC    still works.  Apply power  to  the  TNC      and
  2091.      turn   it    on. The     STA,  CON,  and  PWR LEDs should come on and the STA
  2092.      and CON lights should go out again    about 1    second later.    If  you     have
  2093.      the   type      2764    EPROM with  the     KISS  code  in    it one or both of the
  2094.      STA and CON LEDs will begin to flash.  If the CON LED flashes  you     have
  2095.      8Kb  of  RAM  in the TNC.    If the STA LED flashes    you have 16Kb of RAM.
  2096.      If    both LEDs flash    you have 32 Kb of RAM.    The flashing of    the LEDs ver-
  2097.      ifies the proper operation    of the TNC.
  2098.  
  2099.      2.2.3.  AEA PK-232
  2100.  
  2101.      If    you have one of    these boxes, congratulations!  You do not   have   to
  2102.      change  PROMS!   KISS  is already installed as a standard feature if you
  2103.      have a recent release of the firmware, 4-MAR-87 or    later  for  the      PK-
  2104.      232,   or     21-JAN-87  or later for the PK-87, you    have KISS in your TNC
  2105.      already.  To make it work first ensure that your computer    can  communi-
  2106.      cate  with      the    TNC   in  standard  packet mode.   This     will  ensure
  2107.  
  2108.  
  2109.  
  2110.  
  2111.  
  2112.  
  2113.  
  2114.  
  2115.  
  2116.                       -    33 -
  2117.  
  2118.  
  2119.      that the computer,    TNC, cabling, and radio    are all    operating properly.
  2120.  
  2121.      [Please note that one of the commands "PACKET" is not valid on the      PK-
  2122.      87      and  will only elicit    a "Huh?" response.  Please note    that comments
  2123.      have been added to    the commands.  Do not type the information  following
  2124.      the  double  dash    or type    the double dash    itself.]
  2125.  
  2126.      Here is the sequence of commands that will    turn on     the  KISS  mode  for
  2127.      the  AEA products:
  2128.  
  2129.          AWLEN 8         --    ensure it can speak 8 bit data
  2130.          PARITY 0         --    no parity
  2131.          RESTART         --    warm reset; make commands take effect
  2132.          PACKET         --    PK-232 or Heath    only
  2133.          TONE 3         --    PK-87 only
  2134.          START 0         --    disable    software flow control
  2135.          STOP 0
  2136.          XON 0
  2137.          XOFF 0
  2138.          XFLOW off
  2139.          CONMODE trans   --    pass through all characters
  2140.          HPOLL off         --    disable    host polling
  2141.          KISS on         --    enable KISS version of host mode
  2142.          RAWHDLC on         --    turn off AX25L2    (now handled by    the PC)
  2143.          PPERSIST on     --    turn off DWAIT and enable p-persistence
  2144.          HOST on         --    start KISS running
  2145.  
  2146.      The PK-87 or the PK-232 will remain in the    KISS mode until    you  send   a
  2147.      break  (~200ms of spacing)    or until you send the command character    three
  2148.      times (^C ^C ^C) in quick succession.  Beware!  Some terminal  emulators
  2149.      (like   YAPP)   will  send      a   break  signal  when you exit from    them.
  2150.      That will undo your work and cause    all manner of confusion.  The  termi-
  2151.      nal  program   PROCOMM  seems  to    work just  fine.  The TNC may also be
  2152.      switched back to ordinary AX.25 mode by issuing  the  following  command
  2153.      from within NET.EXE:
  2154.  
  2155.          param ax0 255
  2156.  
  2157.      AEA is rumored to be reworking their software so that entering just  the
  2158.      "KISS" command will do all    of the above. Check your documentation to see
  2159.      how your version works.
  2160.  
  2161.      2.2.4.  Kantronics    TNC's
  2162.  
  2163.      Kantronics    includes KISS support in their products. It is    the  simplest
  2164.      of    the commercial implementations of KISS to configure and    use.
  2165.  
  2166.      First setup and operate your KAM, KPC-II, or KPC-4    for  standard  packet
  2167.      operation.      This will ensure that    the computer, TNC, cabling, and    radio
  2168.      are operating properly. Use your terminal program to send the  following
  2169.      commands:
  2170.  
  2171.          ABAUD 4800         --    baud rate to what you will be using when
  2172.                 net is running (set by the attach command)
  2173.  
  2174.  
  2175.  
  2176.  
  2177.  
  2178.  
  2179.  
  2180.  
  2181.  
  2182.                       -    34 -
  2183.  
  2184.  
  2185.          DWAIT 0         --    disable    DWAIT
  2186.          PERSIST 50         --    enable persistence and set it to about 20%
  2187.          SLOTTIME 16     --    set the    slot time to 160 ms
  2188.          KISS ON         --    Enable KISS mode at the    next reset
  2189.          PERM         --    make above command permanent so    that KISS
  2190.                 will be    entered    whenever TNC is    powered    up
  2191.          RESET         --    start KISS
  2192.  
  2193.      If    you wish to have the the TNC revert back to ordinary AX.25  mode   of
  2194.      opera- tion  you  should  omit the    PERM command from the above sequence.
  2195.      That way the TNC will revert back    to  ordinary  AX.25  mode  when      the
  2196.      power   is     removed  and restored    to  the    TNC.  The TNC may be switched
  2197.      back to ordinary AX.25 mode by issuing the    command:
  2198.  
  2199.          param ax0 255
  2200.  
  2201.      This command will work even if the    PERM command has been  used  to     make
  2202.      KISS the default mode of operation.
  2203.  
  2204.      2.2.5.  Paccomm PC-100 Card
  2205.  
  2206.      There have    been problems in the development of the    driver for this    card,
  2207.      and  though  support  is included in this release,    it is unclear whether
  2208.      the driver    provided works at all, or what the proper  way    to  configure
  2209.      the PC-100    is.  An    individual is working on improving the driver, and we
  2210.      hope to include his results soon.
  2211.  
  2212.      2.2.6.  DRSI
  2213.  
  2214.      DRSI provides a copy of the  KA9Q    package     configured  for  their     card
  2215.      directly.    Contact    DRSI about the current level of    support    they provide.
  2216.      At    some point, their driver will hopefully    be integrated back  into  the
  2217.      mainstream    release.
  2218.  
  2219.      2.3.  IBM PC and Clones
  2220.  
  2221.      2.3.1.  Installing    the Plug'N'Play    Disk
  2222.  
  2223.      For users of IBM PC's and Clones, we try to make life as simple as     pos-
  2224.      sible.   There is a 360k floppy disk available from TAPR (see the appen-
  2225.      dices for contact information) that is almost ready to go.      You  "Plug"
  2226.      the  disk in, edit    a couple of files with your favorite text editor, and
  2227.      then you're ready to "Play". Instructions    on  editting  the  files  are
  2228.      embedded as comments in the files,    with a readme file on the disk to get
  2229.      you started. For completeness, information    about the files     is  included
  2230.      here as well.
  2231.  
  2232.      2.3.1.1.  The AUTOEXEC.NET    File
  2233.  
  2234.      The AUTOEXEC.NET file (called STARTUP.NET under Unix, and    other  things
  2235.      elsewhere)     works    a  lot    like  the AUTOEXEC.BAT file in Dos, hence the
  2236.      name.  When NET first starts up, it reads AUTOEXEC.BAT and    executes  all
  2237.      of     the  commands    as  if they had    been typed in to the program from the
  2238.      keyboard. This provides an    easy mechanism for  setting  up     the  initial
  2239.  
  2240.  
  2241.  
  2242.  
  2243.  
  2244.  
  2245.  
  2246.  
  2247.  
  2248.                       -    35 -
  2249.  
  2250.  
  2251.      system  configuration, including setting the hostname, AX.25 parameters,
  2252.      interfaces    used, servers to start,    and protocol variables.
  2253.  
  2254.      The suggested procedure is    to start with the AUTOEXEC.NET file  included
  2255.      on     the  plug  and     play disk, and    go from    there.    If you don't have the
  2256.      plug and play disk, review    the command summary elsewhere in  this    docu-
  2257.      ment, and wing it...
  2258.  
  2259.      2.3.1.2.  The FTPUSERS File
  2260.  
  2261.      Since MS-DOS was designed as a single-user    operating system,   it     pro-
  2262.      vides  no access  control;     all files can be read,    written    or deleted by
  2263.      the local user.  It is usually undesirable    to give    such open access to a
  2264.      system  to     remote    network     users.    The FTP    server therefore provides its
  2265.      own access    control    mechan-    ism.
  2266.  
  2267.      The file "/ftpusers" is used to control remote FTP    access.     The  default
  2268.      is      NO access; if     this  file  does  not    exist, the FTP server will be
  2269.      unusable. A remote    user must first    "log in" to  the  system,  giving   a
  2270.      valid   name  and    password  listed  in  /ftpusers, before    he or she can
  2271.      transfer files.
  2272.  
  2273.      Each entry    in /ftpusers consists of a single line of the form
  2274.  
  2275.          username password path1 permissions1 path2    permissions2 ...
  2276.  
  2277.      There must    be exactly one space between each  field. Comment  lines  are
  2278.      begun with    "#" in column one.
  2279.  
  2280.      "username"    is the user's login name.
  2281.  
  2282.      "password"    is the required    password. Note    that  this   is      in   plain-
  2283.      text; therefore  it  is  not a good idea to give general read permission
  2284.      to    the root directory. A password of "*" (a single    asterisk) means     that
  2285.      any  password  is acceptable.
  2286.  
  2287.      "/pathN" is an allowable prefix on    accessible files.  Before  any     file
  2288.      or     directory   operation,     the current directory and the user specified
  2289.      file name are joined to form an absolute path name    in "canonical"     form
  2290.      (i.e.,   a     full path  name  starting  at    the root, with "./" and    "../"
  2291.      references, as well as  redundant    /'s,  recognized  and  removed).  The
  2292.      result  MUST  begin with an allowable  path  prefix; if  not, the opera-
  2293.      tion is denied. NB! Under MS-DOS, this field must use backslashes ("/"),
  2294.      NOT  forward  slashes  ("/").  This field    must always begin with a "/",
  2295.      i.e., at the root directory.
  2296.  
  2297.      "permissionsN" is a decimal number    granting permission for    read,  create
  2298.      and  write      operations.  If the low order    bit (0x1) is set, the user is
  2299.      allowed to    read a file subject to the path    name prefix  restriction.  If
  2300.      the   next      bit  (0x2)  is  set,    the  user  is  allowed    to  create  a
  2301.      new file if it does not overwrite an existing file. If  the  third      bit
  2302.      (0x4)   is      set,     the   user   is allowed  to  write a file even    if it
  2303.      overwrites    an existing file, and in addi-    tion  he  may  delete  files.
  2304.      Again,  all  operations  are  allowed  subject  to     the path name prefix
  2305.  
  2306.  
  2307.  
  2308.  
  2309.  
  2310.  
  2311.  
  2312.  
  2313.  
  2314.                       -    36 -
  2315.  
  2316.  
  2317.      restrictions. Permissions may be combined by adding bits,    for  example,
  2318.      0x3  (=  0x2  + 0x1) means    that the user is given read and     create     per-
  2319.      mission, but not overwrite/delete permission.
  2320.  
  2321.      For example, suppose /ftpusers on machine    "pc.ka9q.ampr"    contains  the
  2322.      line
  2323.  
  2324.          friendly test /testdir 7
  2325.  
  2326.      A session using this account would    look like this:
  2327.  
  2328.          net> ftp pc.ka9q.ampr
  2329.          SYN Sent
  2330.          Established
  2331.          250 pc.ka9q.ampr FTP  version  871225.5  ready  at     Wed  Jan  20
  2332.      16:27:18 1988
  2333.          user friendly
  2334.          331 Enter PASS command
  2335.          pass test
  2336.          230 Logged    in
  2337.  
  2338.      The user now has read, write, overwrite and delete     privileges  for  any
  2339.      file under    /testdir; he may not access any    other files.
  2340.  
  2341.      Here are some more    sample entries in /ftpusers:
  2342.  
  2343.      karn foobar / 7     # User    "karn" password    "foobar" may read,
  2344.                  # write, overwrite and    delete any file    on
  2345.                  # system.
  2346.  
  2347.      guest bletch /g/bogus 3 # User    "guest"    password "bletch" may read
  2348.                  # any file under /g/bogus and its subdirs,
  2349.                  # and may create new files that do not
  2350.                  # overwrite existing files. He    may NOT
  2351.                  # delete any files.
  2352.  
  2353.      anonymous * /public 1     # User    "anonymous" (any password) may read
  2354.                  # files under /public and subdir; he may
  2355.                  #  not     create,  overwrite  or     delete      any
  2356.                  # files.
  2357.  
  2358.      The last entry is a standard convention for  keeping  a   repository  of
  2359.      downloadable   files;  in     particular,  the  username "anonymous"    is an
  2360.      established ARPAnet convention.  Every system providing an    FTP server is
  2361.      encouraged    to provide restricted access to    an 'anonymous' user.
  2362.  
  2363.      2.3.1.3.  The HOSTS.NET File
  2364.  
  2365.      The file HOSTS.NET    provides a mapping  between  internet  addresses  and
  2366.      symbolic  hostnames.  It  is used by NET to look up a hostname to figure
  2367.      out the correct IP    address    to use.    This version of    NET does not  include
  2368.      nameserver    support    (see the discussion earlier in this document), and so
  2369.      uses this static file for name lookups.  Tabs  are     recommended  between
  2370.      the  host    number    and  host name.     Here is an example of some HOSTS.NET
  2371.  
  2372.  
  2373.  
  2374.  
  2375.  
  2376.  
  2377.  
  2378.  
  2379.  
  2380.                       -    37 -
  2381.  
  2382.  
  2383.      entries:
  2384.  
  2385.          44.96.0.2         wb2sef xt.wb2sef
  2386.          44.96.0.16         n8fjb
  2387.          44.96.0.17         ka3lyq
  2388.  
  2389.      Note that the domain name .AMPR.ORG has been assigned for amateur radio.
  2390.      By     default,  we  assume that the hostname    is the user's callsign in the
  2391.      case where    a user has one system online, and so  <callsign>.AMPR.ORG  is
  2392.      the  implied official hostname. If    you have more than one machine on the
  2393.      air, distinguish them by prefixing    a familiar name    followed by a period,
  2394.      as    in "winfree.n3eua" or "at.n0ccz".
  2395.  
  2396.      Note that the use of a callsign as    a host name has    nothing     to  do     with
  2397.      the "mycall" parameter.  It is convenient to use the callsign as a    host-
  2398.      name, and required    to use the callsign for    "mycall" to properly identify
  2399.      a station according to FCC    rules.
  2400.  
  2401.      2.3.2.  Installing    on a Hard Disk
  2402.  
  2403.      To    install    the software on    a hard disk, just clone    the directory  struc-
  2404.      ture  and    file  layout from the floppy disk.  All    paths are relative to
  2405.      the root directory    of the current drive.
  2406.  
  2407.      2.4.  Unix
  2408.  
  2409.      To    run NET    under Unix, you'll need    to compile the program from  sources.
  2410.      To    do so, unpack the source archive into a    directory, edit    the beginning
  2411.      of    makefile.unx to    pick your Unix variant,    edit config.h to  enable  the
  2412.      appropriate interface hardware (slip and kiss are probably    all that will
  2413.      work), the    run 'make -f makefile.unx'.  There's nothing wrong with    copy-
  2414.      ing  the  makefile.unx  file to makefile and doing    the editting there...
  2415.      personal preference.
  2416.  
  2417.      The basic requirements are    that the serial    ports to be used by net     must
  2418.      have  their  permissions  set so that they    are read-write for the userid
  2419.      that will run net.    For example, you can define a user  named  'net'  and
  2420.      make that user own    tty000 and tty001. The protection for the ttys should
  2421.      be    crw------- (600). Logins must be turned    off  for  those     ports,     i.e.
  2422.      there  must not be    any other process, such    as a getty or init, trying to
  2423.      access them. The attach line is virtually the same    as for the PC, except
  2424.      that  the I/O address argument is ignored and the I/O vector argument is
  2425.      now the tty name. For example:
  2426.  
  2427.          attach asy    0 /dev/tty000 ax25 ax0 2048 256    4800
  2428.  
  2429.          attach asy    0 /dev/tty001 ax25 ax1 2048 256    4800
  2430.  
  2431.      The Unix version of Net uses  two    environment  variables,     NETHOME  and
  2432.      NETSPOOL. A possible configuration    might be
  2433.  
  2434.          NETHOME=/usr/net          NETSPOOL=/usr/spool
  2435.  
  2436.      The directories needed are    /usr/net, /usr/net/finger,  /usr/spool/mail/,
  2437.  
  2438.  
  2439.  
  2440.  
  2441.  
  2442.  
  2443.  
  2444.  
  2445.  
  2446.                       -    38 -
  2447.  
  2448.  
  2449.      and  /usr/spool/mqueue.  See  also     the  documentation  on     the W2XO BBS
  2450.      (sources and documentation    are included in    the NET    source distribution),
  2451.      as     there    are some important interactions    if you intend to run the PBBS
  2452.      code with NET under Unix.
  2453.  
  2454.      The Unix version of NET currently supports    only serial ports,  with  the
  2455.      KISS and SLIP protocols.
  2456.  
  2457.      2.5.  Macintosh
  2458.  
  2459.      This release does not include Macintosh code.  A separate group is    work-
  2460.      ing  on  the  Macintosh,  using  the  same     system     independent protocol
  2461.      modules, but with a user interface    that is    much more closely related  to
  2462.      the expected Macintosh environment.
  2463.  
  2464.      Installation documentation    for the    Mac is included    with the Mac  version
  2465.      of    the software, available    from <insert contact info here>.
  2466.  
  2467.      2.6.  Atari ST
  2468.  
  2469.      Installation for the Atari    version    of NET is not  yet  available.     Your
  2470.      best bet is to stare at the sources, in config.h and files.h, as well as
  2471.      st.c and st.h. We hope to include documentation in    the next revision  of
  2472.      this manual.
  2473.  
  2474.      2.7.  NEC PC-9801
  2475.  
  2476.      Installation on the NEC PC-98 family is the same as for the IBM  PC  and
  2477.      clones,  except  that  you     need  to  have     the  version of NET.EXE that
  2478.      includes handling for the serial port(s) in the NEC machine.
  2479.  
  2480.      2.8.  Hewlett-Packard Portable Plus
  2481.  
  2482.      Installation on the Portable Plus is the same as  for  the     IBM  PC  and
  2483.      clones,  except  that  you     need  to have the version of NET.EXE that is
  2484.      designed for the Portable Plus.
  2485.  
  2486.  
  2487.  
  2488.  
  2489.  
  2490.  
  2491.  
  2492.  
  2493.  
  2494.  
  2495.  
  2496.  
  2497.  
  2498.  
  2499.  
  2500.  
  2501.  
  2502.  
  2503.  
  2504.  
  2505.  
  2506.  
  2507.  
  2508.  
  2509.  
  2510.  
  2511.  
  2512.                       -    39 -
  2513.  
  2514.  
  2515.      3.     Taking    NET for    a Test Drive
  2516.  
  2517.      For the quick introduction    to NET provided    in this     section,  we  assume
  2518.      that you are using    an IBM PC or clone with    the Plug'n'Play    disk. We also
  2519.      assume that you've    already    configured the disk per    in  the     installation
  2520.      instructions.   Finally,  we  assume  a TNC has been set up as interface
  2521.      'ax0'.
  2522.  
  2523.      3.1.  Trying out the AX.25    Support
  2524.  
  2525.      Start by typing 'NET' to get the program up and running.  You should  be
  2526.      presented    with  a    banner including revision information and a copyright
  2527.      statement,    followed by a prompt of    'net>'.    If you don't get this,    some-
  2528.      thing is horribly wrong. Find a friend and    ask for    help.
  2529.  
  2530.      Once you have the program going at    all, the first thing you'll  probably
  2531.      want  to  do  is  to  figure  out if the TNC is hooked up correctly, and
  2532.      whether you're getting out    at all.     To get    connected, you    do  basically
  2533.      the  same thing you'd do with a raw TNC.  Type 'connect ax0 <callsign>',
  2534.      where <callsign> is someone's callsign who    is known to be    on  the     air.
  2535.      You  can  also  specify a digipeater string. For example, you could type
  2536.      one of:
  2537.  
  2538.       connect ax0 n3eua         (connect using    the ax0    TNC to N3EUA)
  2539.       connext ax0 n3eua n1fed n0ccz     (conn to N3EUA    via N1FED and N0CCZ)
  2540.  
  2541.      If    all is well, you should    get "Conn Pending" and then "Connected"     mes-
  2542.      sages.  At    this point, you're connected just like using a plain old TNC.
  2543.      Kind of boring, huh?  It'll get more exciting soon!
  2544.  
  2545.      When you're ready to disconnect, use the <F10> key    to  escape  from  the
  2546.      session back to the 'net>'    prompt,    and then type 'disconnect'.  You will
  2547.      discover that all commands    can be abbreviated, and    you can    type a
  2548.  
  2549.      If    things don't work, watch the lights on    the  TNC  to  see  if  you're
  2550.      transmitting  at  all, then go read up on the "trace" command so you can
  2551.      see what the program thinks it's doing.  Even easier, if there's someone
  2552.      else using    TCP in your area, ask for help!
  2553.  
  2554.      3.2.  The Telnet Command
  2555.  
  2556.      If    there's    someone    else on    the air    in your    area  already  using  TCP/IP,
  2557.      then  the    next  most  easy  thing    to do is to try    a keyboard connection
  2558.      using the Telnet protocol.    The end    result will be the same    as  doing  an
  2559.      AX.25  connect in most cases, but you'll be taking    advantage of a couple
  2560.      of    neat attributes    of having more protocol    horsepower to help you out.
  2561.  
  2562.      First, you    need to    either know the    numeric    IP address of  your  friend's
  2563.      system, or    you need to have updated HOSTS.NET to include the system name
  2564.      and the numeric address.  Then all    you have to do is type:
  2565.  
  2566.       telnet n3eua          (talk    to N3EUA, address in HOSTS.NET)     tel-
  2567.       net [44.32.0.4]      (use the    numeric    address    directly)
  2568.  
  2569.  
  2570.  
  2571.  
  2572.  
  2573.  
  2574.  
  2575.  
  2576.  
  2577.  
  2578.                       -    40 -
  2579.  
  2580.  
  2581.      Now you can type back and forth just as if    you  were  connected  with  a
  2582.      normal  TNC.  When    you're done, use the <F10> key to escape back to com-
  2583.      mand mode,    and then type 'close' to close the connection gracefully,  or
  2584.      'reset' if    you're really in a hurry.
  2585.  
  2586.      3.3.  The FTP Command
  2587.  
  2588.      So    far, all we've done is to use more software and    work harder to do the
  2589.      same  things we can do with a plain old TNC.  The FTP command isn't like
  2590.      that!  If you want    to get a file from your     friends'  machine,  you  can
  2591.      type the command:
  2592.  
  2593.       ftp n3eua
  2594.      to    start a    file transfer session to the N3EUA machine.  When the connec-
  2595.      tion is opened, you'll get    a banner from the remote machine, followed by
  2596.      a prompt for your user name.  If you've negotiated    with your  friend  to
  2597.      have  a  special  username     and  password set up for you in his FTPUSERS
  2598.      file, use that. If    not, many machines allow arbitrary users to get     lim-
  2599.      ited  access to the files available with a    special    username 'anonymous'.
  2600.      If    you want to use    the 'anonymous'    login, when  you're  prompted  for  a
  2601.      password  enter  your  callsign  or something else    recognizable, as many
  2602.      folks keep    a log of FTP's so they know what files people care about, and
  2603.      being able    to associate your activities with you sometimes    helps.
  2604.  
  2605.      3.4.  The Mail System
  2606.  
  2607.      The mail system is    a subject unto itself. It is also one  of  the    truly
  2608.      nifty  things about running TCP/IP.  Look elsewhere in the    documentation
  2609.      for a complete rundown on how to install and operate the BM mailer,  and
  2610.      the portions of NET related to it.
  2611.  
  2612.      3.5.  Tracing and Status Commands
  2613.  
  2614.      The tracing and status commands provide  a     great    deal  of  information
  2615.      about  what  is  going on in the system. All we'll    attempt    to do here is
  2616.      raise your    interest level.
  2617.  
  2618.      If    you want to find out what  sessions  are  active  to  and  from     your
  2619.      machine,  you can type 'sessions' and you'll get a    list.  If you want to
  2620.      get information about all of the TCP connections open to and  from     your
  2621.      machine,  including  mail transfers and other things that don't directly
  2622.      interact with your    keyboard and screen, you can type  "tcp     status"  and
  2623.      you'll get    a list of connections.
  2624.  
  2625.      If    you're not sure    what's happening on an interface, or  you'd  like  to
  2626.      "read  the    mail" (watch what other    folks are doing    ont he channel), then
  2627.      use the "trace" command.  The form    is descibed in the command  reference
  2628.      elsewhere in this document.  For example:
  2629.  
  2630.       trace    ax0 111        (activity on ax0, including ASCII dump)    trace
  2631.       ax0  211       (activity on    ax0, including hex dump) trace ax0 11
  2632.       (activity on ax0, printing only the headers)
  2633.  
  2634.      Note that you also    have control over whether tracing can bother you in a
  2635.  
  2636.  
  2637.  
  2638.  
  2639.  
  2640.  
  2641.  
  2642.  
  2643.  
  2644.                       -    41 -
  2645.  
  2646.  
  2647.      session, see the trace command summary for    more details.
  2648.  
  2649.  
  2650.  
  2651.  
  2652.  
  2653.  
  2654.  
  2655.  
  2656.  
  2657.  
  2658.  
  2659.  
  2660.  
  2661.  
  2662.  
  2663.  
  2664.  
  2665.  
  2666.  
  2667.  
  2668.  
  2669.  
  2670.  
  2671.  
  2672.  
  2673.  
  2674.  
  2675.  
  2676.  
  2677.  
  2678.  
  2679.  
  2680.  
  2681.  
  2682.  
  2683.  
  2684.  
  2685.  
  2686.  
  2687.  
  2688.  
  2689.  
  2690.  
  2691.  
  2692.  
  2693.  
  2694.  
  2695.  
  2696.  
  2697.  
  2698.  
  2699.  
  2700.  
  2701.  
  2702.  
  2703.  
  2704.  
  2705.  
  2706.  
  2707.  
  2708.  
  2709.  
  2710.                       -    42 -
  2711.  
  2712.  
  2713.      4.     The Mail System
  2714.  
  2715.      As    is typical with    networking  software,  handling     electronic  mail  is
  2716.      often  as    big a job as coping with all other applications    combined.  In
  2717.      order to make full    use of the mail    system in the KA9Q package, you     will
  2718.      need to spend a little time getting things    configured for your system.
  2719.  
  2720.      4.1.  Installing and Using    BM
  2721.  
  2722.      The BM.EXE    mail user interface program  was  created  by  Bdale  Garbee,
  2723.      N3EUA,  and  despite  popular  belief,  'BM'  really stands for "Bdale's
  2724.      Mailer".  Gerard van der Grinten  PA0GRI  extended     the  mailer  with  a
  2725.      number  of    new features that resulted in version 2.  More recently, Dave
  2726.      Trulli NN2Z has extended the mailer creating revision 3.    All  comments
  2727.      or    suggestions about BM should be directed    to Dave.
  2728.  
  2729.      BM    provides a full    set of mail services to    the user which allow  sending
  2730.      and  receiving electronic mail, as    well as    a variety of local mail    mani-
  2731.      pulation commands.
  2732.  
  2733.      4.1.1.  Installation
  2734.  
  2735.      To    install    BM requires the    modification  of  the  supplied    configuration
  2736.      files  and     the  creation    of  the     proper    directory structure. The fol-
  2737.      lowing sections describe  the file    and directory structure     used  by  BM
  2738.      and SMTP.
  2739.  
  2740.      4.1.1.1.  Directory Structure
  2741.  
  2742.      /spool/mqueue   This directory  holds  the     outbound  mail
  2743.              jobs  for    SMTP.  Each  job  consists of 2
  2744.              files a xxxx.txt and xxxx.wrk  file  where
  2745.              xxxx  is  a  unique numerical prefix.  The
  2746.              format of the files  are  described  in  a
  2747.              later section.
  2748.  
  2749.      /spool/rqueue   This directory is used by    SMTP  for  jobs
  2750.              that   have  been    received  and  will  be
  2751.              processed by a user defined  mail    routing
  2752.              program.     This  directory  is  not  used
  2753.              directly by BM.
  2754.  
  2755.      /spool/mail     This  directory   holds   the   individual
  2756.              mailboxes    for  each  user     name  on  your
  2757.              system. The extension .txt    is add    to  the
  2758.              user  name     to form the mailbox name. Mail
  2759.              received by the SMTP server is appended to
  2760.              the mailbox file.
  2761.  
  2762.      4.1.1.2.  Configuration File
  2763.  
  2764.      The /bm.rc    file provides  BM  with     the  configuration  needed  for  the
  2765.      operation of the mailer.
  2766.  
  2767.  
  2768.  
  2769.  
  2770.  
  2771.  
  2772.  
  2773.  
  2774.  
  2775.  
  2776.                       -    43 -
  2777.  
  2778.  
  2779.      The format    for the    /bm.rc file is:
  2780.  
  2781.          variable <space>  value <newline>
  2782.  
  2783.      The following variables are valid in the bm.rc file:
  2784.  
  2785.  
  2786.      4.1.1.2.1.     smtp <path>
  2787.  
  2788.      Defines the path to the directory containing  the    mailbox    files.      The
  2789.      default  directory     is  /spool/mail  on  the current drive.
  2790.  
  2791.      4.1.1.2.2.     host <your hostname>
  2792.  
  2793.      Is    used to    set the    local hostname for use    in  the     RFC822    mail headers.
  2794.      This  is a    required field.     This should match the hostname    definition in
  2795.      autoexec.net.
  2796.  
  2797.      4.1.1.2.3.     user <username>
  2798.  
  2799.      Defines the user name of the person who is     sending  mail.     This is also
  2800.      used  as  the  default mailbox for    reading    mail.  On the AMPRNET this is
  2801.      usually set to your call.    There is a DOS limit of    8 characters for  the
  2802.      user name.
  2803.  
  2804.      4.1.1.2.4.     edit <path of your editor>
  2805.  
  2806.      Defines the name of your favorite editor which can    be used    to  construct
  2807.      and  edit the text    of outgoing messages.  The use of edit is optional.
  2808.  
  2809.      4.1.1.2.5.     fullname <your    full name>
  2810.  
  2811.      Is    used to    provide    your full name to the mailer for use in    the   comment
  2812.      portion  of "From:" header    line.  The use of fullname is optional.
  2813.  
  2814.      4.1.1.2.6.     reply <return address>
  2815.  
  2816.      Defines the address where you wish     to  receive   replies     to  messages
  2817.      sent.   This  option  is  useful if you are operating your    pc on a    local
  2818.      area network and would like  your    mail replies  sent  to    a  more    "well
  2819.      known  host".  The    address    specified by reply  is    used  to  generate  a
  2820.      "Reply-To:" header     in outbound mail. The "Reply-To:"  header  overrides
  2821.      the  "From:"  header  which  is  the address normally  used  to reply to
  2822.      mail. This    field is optional.
  2823.  
  2824.      4.1.1.2.7.     maxlet    <number    of messages>
  2825.  
  2826.      defines  the  maximum  number  of    messages  that    can  be    processed  by
  2827.      BM     in one    mailbox    file. The default value    of maxlet is 100.
  2828.  
  2829.      4.1.1.2.8.     mbox <filename>
  2830.  
  2831.      Specifies the default file     to  be      used     for   the   "save"  command.
  2832.      This  file     is  in     the same format as a mailbox and may later be viewed
  2833.  
  2834.  
  2835.  
  2836.  
  2837.  
  2838.  
  2839.  
  2840.  
  2841.  
  2842.                       -    44 -
  2843.  
  2844.  
  2845.      using the -f option  of  BM.  If  this  option  is     not  used  then  the
  2846.      default is    set to mbox.
  2847.  
  2848.      4.1.1.2.9.     record    <filename>
  2849.  
  2850.      If    defined    a copy of each message sent will  be  saved  in    <filename>.
  2851.  
  2852.      4.1.1.2.10.  folder <directory name>
  2853.  
  2854.      If    defined    folder contains     the  path  used  by  the  save    command.
  2855.  
  2856.      4.1.1.2.11.  screen [bios|direct]
  2857.  
  2858.      In    the Turboc compiled version  of     BM,  screen  sets  the    display     out-
  2859.      put  mode to use either direct writes to screen memory or the ROM    BIOS.
  2860.      The  default  is  direct  which provides  the   fastest   output    mode.
  2861.      If     you are using a windowing system such as Desqview you should set the
  2862.      mode to bios.
  2863.  
  2864.      4.1.1.2.12.  Example BM.RC    File
  2865.  
  2866.       host nn2z.ampr user dave fullname Dave Trulli    # send my replies  to
  2867.       the  Sun  reply  nn2z@ka9q.bellcore.com screen  direct edit /bin/vi
  2868.       mbox c:/folder/mbox record c:/folder/outmail folder c:/folder     max-
  2869.       let 200
  2870.  
  2871.      4.1.1.3.  The ....lias File
  2872.  
  2873.      The alias file provides  an  easy way to  maintain     mailing  lists.   An
  2874.      alias  can     be  any  string of characters not containing the "@" symbol.
  2875.      The  format for the alias file is:
  2876.  
  2877.             alias   recip1 recip2 recip3
  2878.             <tab>   recip4
  2879.  
  2880.      Note that a long list of aliases can be  continued      on   an  additional
  2881.      line  by  placing    a  tab    or  space  on  the continuation    line.
  2882.  
  2883.      Some examples aliases are:
  2884.  
  2885.             dave    nn2z@nn2z.ampr
  2886.  
  2887.             phil    karn@ka9q.bellcore.com
  2888.  
  2889.             # mail to local nnj    users
  2890.             nnj        wb2cop@wb2cop.ampr karn@ka9q.bellcore.com
  2891.                 wb0mpq@home.wb0mpq.ampr w2kb@w2kb.ampr
  2892.  
  2893.      In     the  above  example,  when  specifying     nnj    as    the  recipient,
  2894.      BM     will  expand  the  alias  into    the list of recipients from the    alias
  2895.      file.  At this time an alias may not contain any other aliases.
  2896.  
  2897.  
  2898.  
  2899.  
  2900.  
  2901.  
  2902.  
  2903.  
  2904.  
  2905.  
  2906.  
  2907.  
  2908.                       -    45 -
  2909.  
  2910.  
  2911.      4.1.1.4.  /spool/mqueue/sequence.seq The sequence file maintains a     mes-
  2912.      sage  counter  which  is used by BM and SMTP to generate message ids and
  2913.      unique filenames. This file is created if not already present by BM.
  2914.  
  2915.      4.1.2.  Environment
  2916.  
  2917.      The timezone used in mail headers is obtained from    the  DOS  environment
  2918.      variable TZ. An example TZ    setting    is:
  2919.  
  2920.          set TZ=EDT4
  2921.  
  2922.      It     is  set  in  your  AUTOEXEC.BAT  file.     The   first    3  characters
  2923.      are   the    timezone and the fourth    character is the number    of hours from
  2924.      GMT time. If TZ is    not  set,  GMT is assumed.
  2925.  
  2926.      4.2.  Commands
  2927.  
  2928.      All BM commands are single    letters     followed   by     optional  arguments.
  2929.      The  command  list     has been designed to make those familiar with Berke-
  2930.      ley mailers comfortable with BM.
  2931.  
  2932.      4.2.1.  Main Menu Commands
  2933.  
  2934.      4.2.1.1.  m [userlist]
  2935.  
  2936.      The mail command is used to send a    message    to one or   more  recipients.
  2937.      All  local     recipient  names  (  those  which don't contain an '@'    ) are
  2938.      checked for possible aliases.  If    no  arguments     are   supplied      you
  2939.      will   be     prompted   for      a recipient list.  While entering a message
  2940.      into  the    text buffer several commands are available such    as:  invoking
  2941.      an     editor,  and reading in text from other messages or  files.  See the
  2942.      section below for a description of    these commands.      To  end  a  message
  2943.      enter a line containing a single period.
  2944.  
  2945.      It    is important to    remember that the input    line buffer has    a  128    char-
  2946.      acter   limit.   You   should  format  your  text by entering a carriage
  2947.      return at the end of each line. Typing excessively       long      lines      may
  2948.      cause   data   loss  due  to truncation when passing the message through
  2949.      other  hosts.  Keeping  lines  less  than    80  characters    is  always  a
  2950.      good idea.
  2951.  
  2952.      4.2.1.2.  d [msglist]
  2953.  
  2954.      Mark messages for deletion.  Messages marked for  deletion    are   removed
  2955.      when   exiting  BM     via the 'q' command or    when changing to an alternate
  2956.      mailbox with the 'n' command.
  2957.  
  2958.      4.2.1.3.  h
  2959.  
  2960.      Display message headers.  The  message  headers   contain     the  message
  2961.      number,  the  status indicating whether it    has been read or deleted, the
  2962.      sender, size, date, and subject.
  2963.  
  2964.  
  2965.  
  2966.  
  2967.  
  2968.  
  2969.  
  2970.  
  2971.  
  2972.  
  2973.  
  2974.                       -    46 -
  2975.  
  2976.  
  2977.      4.2.1.4.  u [msglist]
  2978.  
  2979.      Undelete a    message    that is    marked for deletion. The status    of   a     mes-
  2980.      sage   can     be  determined    by looking at the status field of the message
  2981.      using the 'h' command.
  2982.  
  2983.      4.2.1.5.  n [mailbox]
  2984.  
  2985.      Display or    change mailbox.     The  'n'  command  with  no  arguments     will
  2986.      display   a   list     of mailboxes containing mail. If an argument is sup-
  2987.      plied, then the current mailbox  is  closed and a new mailbox is opened.
  2988.  
  2989.      4.2.1.6.  ! cmd
  2990.  
  2991.      Run a DOS command from inside BM. An  error   message   will  result  if
  2992.      there is not enough memory    available to load the command.
  2993.  
  2994.      4.2.1.7.  ?
  2995.  
  2996.      Print a help menu for BM commands.
  2997.  
  2998.      4.2.1.8.  s [msglist] [file]
  2999.  
  3000.      The 's' command is    used to    save messages in a  file.   If     no  filename
  3001.      is      given     the default from the mbox variable in /bm.rc is used.    If no
  3002.      message number is supplied    then the current  message   is     saved.      The
  3003.      message  is  stored  in  the same format as a mailbox file    with all mail
  3004.      headers  left intact.
  3005.  
  3006.      4.2.1.9.  p [msglist]
  3007.  
  3008.      The 'p' command is    used to    send  messages    to  the     printer.  This     com-
  3009.      mand   uses  the  DOS device PRN for output.  This    command    is equivalent
  3010.      to:
  3011.       s [ msglist ]    PRN
  3012.  
  3013.      4.2.1.10.    w [msglist] file
  3014.  
  3015.      The 'w' command is    used to    save messages in a  file.  Only     the  message
  3016.      body   is    saved. All mail    headers    are removed.  If no message number is
  3017.      supplied then the current message    is saved.
  3018.  
  3019.      4.2.1.11.    f [msg]
  3020.  
  3021.      The 'f' command is    used to    forward    a mail message to another  recipient.
  3022.      If     no message number is supplied the current message is used.  The user
  3023.      is    prompted for the  recipients and  a  subject. The  RFC822  header  is
  3024.      added  to the message text    while retaining    the complete original message
  3025.      in     the body.  Also see the ~m command.
  3026.  
  3027.      4.2.1.12.    b [msg]
  3028.  
  3029.      Bounce a message. Bounce  is  similar  to    forwarding  but     instead   of
  3030.      your    user    information,    the   original  sender  information   is
  3031.  
  3032.  
  3033.  
  3034.  
  3035.  
  3036.  
  3037.  
  3038.  
  3039.  
  3040.                       -    47 -
  3041.  
  3042.  
  3043.      maintained.   If  no  message  number  is supplied    the  current  message
  3044.      is    used.
  3045.  
  3046.      4.2.1.13.    r [msg]
  3047.  
  3048.      Reply to a    message. Reply reads the header     information   in  order   to
  3049.      construct    a  reply  to the sender. The destination information is    taken
  3050.      from  the    "From:"     or  the  "Reply-To:" header,  if  included.   If  no
  3051.      message number is supplied    the current message is used.
  3052.  
  3053.      4.2.1.14.    msg#
  3054.  
  3055.      Entering  a message number    from the  header   listing   will  cause  the
  3056.      message text to be    displayed.
  3057.  
  3058.      4.2.1.15.    l
  3059.  
  3060.      List outbound messages.  The job number, the  sender,  and    the  destina-
  3061.      tion  for    each message is    displayed. A status of "L" will    appear if the
  3062.      SMTP sender has the file locked.
  3063.  
  3064.      4.2.1.16.    k [msglist]
  3065.  
  3066.      Remove an outbound    message    from the mqueue.  A message can     be   removed
  3067.      from   the     send  queue  by specifying the    job number obtained by the  l
  3068.      command.    If  the     message  is locked  you will be warned    that you  may
  3069.      be     removing  a  file  that  is  currently    being sent by SMTP. You     will
  3070.      asked  if this job    should still be    killed.
  3071.  
  3072.      4.2.1.17.    $
  3073.  
  3074.      Update the    mailbox.  This     command   updates   the   mailbox,  deleting
  3075.      messages    marked for deletion and    reading    in any new mail    that may have
  3076.      arrived since entering BM.
  3077.  
  3078.      4.2.1.18.    x
  3079.  
  3080.      Exit to DOS without changing the data in the mailbox.
  3081.  
  3082.      4.2.1.19.    q
  3083.  
  3084.      Quit to DOS updating the mailbox.
  3085.  
  3086.      4.2.2.  Text Input    Commands
  3087.  
  3088.      The  following  commands  are  available  while   entering    message     text
  3089.      into the message buffer.
  3090.  
  3091.       ~r <filename>     read <filename> into the message buffer.
  3092.  
  3093.       ~m <msg #>     read <msg #> into the message buffer.
  3094.  
  3095.       ~p         display the text in the message buffer.
  3096.  
  3097.  
  3098.  
  3099.  
  3100.  
  3101.  
  3102.  
  3103.  
  3104.  
  3105.  
  3106.                       -    48 -
  3107.  
  3108.  
  3109.       ~e         invoke    the editor defined in /bm.rc with  a
  3110.              temporary  file  containing the text in the
  3111.              message buffer.
  3112.  
  3113.       ~q         Abort the current message. No data is sent.
  3114.  
  3115.       ~~         Insert    a single tilda    character  into     the
  3116.              message.
  3117.  
  3118.       ~?         Display help menu of tilda escape commands.
  3119.  
  3120.      4.2.3.  Command Line Options BM may be invoked as follows:
  3121.  
  3122.      To    send mail:
  3123.       bm [ -s subject ] recip1 .. .. recipN
  3124.  
  3125.      To    read mail:
  3126.       bm [ -u mailbox | -f file ]
  3127.  
  3128.            -s subject     This option sets the subject to the text on
  3129.                   the command line.
  3130.  
  3131.            -u mailbox     Specify  which  mailbox  to   read.   This
  3132.                   overides the default from    the bm.rc.
  3133.  
  3134.            -f file          Read  message  from  "file"  instead  of    a
  3135.                   mailbox.
  3136.  
  3137.      4.3.  Technical Information
  3138.  
  3139.      4.3.1.  Outbound Mail Queue File Formats
  3140.  
  3141.      Outgoing mail messages consist of two files each in  the    /spool/mqueue
  3142.      direc-  tory.    The   names   of     the  two  files  will be of the form
  3143.      <integer>.WRK and <integer>.TXT, where integer is the sequence number of
  3144.      the message relative to this  machine.   The  file     sequence.seq  in the
  3145.      mqueue directory contains the current sequence number for    reference  by
  3146.      the  mail user  interface.      The  .TXT file contains the data portion of
  3147.      the SMTP transaction, in full RFC822 format.  The .WRK file consists  of
  3148.      3 or more lines, as follows:
  3149.  
  3150.       the hostname of the destination system
  3151.  
  3152.       the full sender address, in user@host    format.
  3153.  
  3154.       some number of full destination addresses, in    user@host format.
  3155.  
  3156.      4.3.2.  Standards Documents
  3157.  
  3158.      The SMTP specification is RFC821. The Format for text messages  (includ-
  3159.      ing  the headers) is in RFC822. RFC819 discusses hostname naming conven-
  3160.      tions, particularly domain    naming.
  3161.  
  3162.  
  3163.  
  3164.  
  3165.  
  3166.  
  3167.  
  3168.  
  3169.  
  3170.  
  3171.  
  3172.                       -    49 -
  3173.  
  3174.  
  3175.      4.4.  Bug Reports
  3176.  
  3177.      Please send any comments, suggestions or bug reports about    BM to:
  3178.  
  3179.       Dave    Trulli    Usenet:     nn2z@ka9q.bellcore.com      packet:   nn2z@nn2z
  3180.       AMPRNET: nn2z@nn2z.ampr [44.64.0.10]
  3181.  
  3182.  
  3183.  
  3184.  
  3185.  
  3186.  
  3187.  
  3188.  
  3189.  
  3190.  
  3191.  
  3192.  
  3193.  
  3194.  
  3195.  
  3196.  
  3197.  
  3198.  
  3199.  
  3200.  
  3201.  
  3202.  
  3203.  
  3204.  
  3205.  
  3206.  
  3207.  
  3208.  
  3209.  
  3210.  
  3211.  
  3212.  
  3213.  
  3214.  
  3215.  
  3216.  
  3217.  
  3218.  
  3219.  
  3220.  
  3221.  
  3222.  
  3223.  
  3224.  
  3225.  
  3226.  
  3227.  
  3228.  
  3229.  
  3230.  
  3231.  
  3232.  
  3233.  
  3234.  
  3235.  
  3236.  
  3237.  
  3238.                       -    50 -
  3239.  
  3240.  
  3241.      5.     NET/ROM Support
  3242.  
  3243.      5.1.  Introduction    The NET/ROM support for    the KA9Q package serves    three
  3244.      purposes:
  3245.  
  3246.          1)    Existing NET/ROM networks may be used to send IP traffic.
  3247.  
  3248.          2)    NET may    be used    as a NET/ROM packet switch.
  3249.  
  3250.          3)    NET may    be used    to communicate with NET/ROM  nodes,  and  its
  3251.          mailbox  facility  can    accept connects    over the NET/ROM net-
  3252.      work.
  3253.  
  3254.      5.2.  Setting up the NET/ROM Interface
  3255.  
  3256.     No physical interface is completely dedicated to net/rom, which    is as
  3257.      it     should     be.  You attach all your AX.25    interfaces, of whatever    sort.
  3258.      Then you attach the net/rom pseudo-interface  ("attach  netrom").     Then
  3259.      you  identify to the net/rom software those interfaces you    want to    allow
  3260.      it    to use,    with the "netrom interface" command.  The format of this com-
  3261.      mand is:
  3262.  
  3263.          netrom interface ax0 #ipnode 192
  3264.  
  3265.      The first argument    is the name of the previously attached interface  you
  3266.      want  to use.  The    second argument    is the alias of    your node, to be used
  3267.      in    your routing broadcasts.  The alias is never used for  anything     else
  3268.      (as  you  will  see!).   The  last    number is the net/rom quality figure.
  3269.      This is used in computing the route qualities; it represents the contri-
  3270.      bution  of     this  interface to the    overall    computation.  For a 1200 baud
  3271.      half-duplex connection, 192 is the    right number.
  3272.  
  3273.     You need a netrom interface command for    every interface    you're    going
  3274.      to    use with net/rom.
  3275.  
  3276.      5.3.  Tracing on the NET/ROM Interface
  3277.  
  3278.     If you want to trace your NET/ROM datagrams,  don't  try  turning  on
  3279.      trace  mode for the "netrom" interface.  Nothing will break, but nothing
  3280.      will happen.  You should trace the    individual AX.25 interfaces instead.
  3281.  
  3282.      5.4.  Routing Broadcasts
  3283.  
  3284.     Once you have set up your interfaces, you need to  set    some  timers.
  3285.      There are two:  the nodes broadcast interval timer, and the obsolescence
  3286.      timer.  These are set in seconds, like the    smtp timer.  You should     usu-
  3287.      ally  set    them to    an hour.  You can set them to something    different, if
  3288.      you want.    If your    local net/rom nodes broadcast  every  hour,  but  you
  3289.      want to do    so every ten minutes, you can say:
  3290.  
  3291.          netrom nodetimer 600      netrom obsotimer 3600
  3292.  
  3293.      Every time    the obsotimer kicks, the obsolescence  counts  for  all     non-
  3294.      permanent    entries     are decremented by one.  When the count for an    entry
  3295.  
  3296.  
  3297.  
  3298.  
  3299.  
  3300.  
  3301.  
  3302.  
  3303.  
  3304.                       -    51 -
  3305.  
  3306.  
  3307.      falls below five, it is no    longer broadcast.  When    it falls to 0, it  is
  3308.      removed.  The count is initialized    at 6.  These will eventually be    sett-
  3309.      able parameters; you can adjust them now by  changing  the     initializers
  3310.      for the variables in the source file.
  3311.  
  3312.     When you first come on the air,    you can    send out nodes broadcasts  to
  3313.      tell the local nodes that you are available.  Use the command:
  3314.  
  3315.          netrom bcnodes ax0
  3316.  
  3317.      where ax0 is the interface    on which you want to send the broadcast.   Do
  3318.      this for every interface on which you want    to do this.
  3319.  
  3320.     By default, the    NET/ROM    code does not broadcast    the contents of     your
  3321.      routing  table.   This is as it should be,    since usually we just want to
  3322.      be    the endpoints of communications    rather than relaying NET/ROM traffic.
  3323.      If    you want to be a switch    station, include the command:
  3324.  
  3325.          netrom verbose yes
  3326.  
  3327.      in    your autoexec.
  3328.  
  3329.     Sometimes you can hear broadcasts from nodes that can't    hear you.  If
  3330.      your  routing  table  gets     filled    with these unusable routes, your node
  3331.      will grind    to a halt.  The    solution to this is node broadcast filtering,
  3332.      via  the  netrom nodefilter command.  There is a filter list, which con-
  3333.      tains a list of callsigns and interfaces.    Then there is a    filter    mode,
  3334.      which indicates what to do    with the list.
  3335.  
  3336.     If the filter mode is  "none",    no  filtering  is  done.   If  it  is
  3337.      "accept",    then only broadcasts from the indicated    stations on the    indi-
  3338.      cated interfaces are accepted.  If    it is "reject",    then  all  broadcasts
  3339.      except  those  from  the  listed  stations     on the    listed interfaces are
  3340.      accepted.
  3341.  
  3342.     Because    the net/rom code  cannot  at  this  time  recognize  unusable
  3343.      routes  and  try alternates, I strongly recommend use of the filter com-
  3344.      mand to restrict broadcast    acceptance to those nodes which    you know  you
  3345.      can reach.
  3346.  
  3347.      5.5.  The NET/ROM Routing Table
  3348.  
  3349.     The next net/rom commands are those used for maintaining the  routing
  3350.      table.   They  fall  under     the "netrom route" subcommand.     "netrom add"
  3351.      adds a permanent entry to the routing table.  Its format is:
  3352.  
  3353.          netrom route add #foo w9foo ax0 192 w9rly
  3354.  
  3355.      This command adds an entry    for w9foo, whose alias is #foo,    route quality
  3356.      192,  via    w9rly  on  interface  ax0.  Let's talk about what this means.
  3357.      w9foo is the *destination*    node, the one to whom you  want     the  packets
  3358.      routed  by     the  net/rom network.    w9rly is your *neighbor*, the net/rom
  3359.      node to which you pass the    packet to  be  forwarded.   Since  w9rly  may
  3360.      appear on more than one interface (the callsign may be used by more than
  3361.  
  3362.  
  3363.  
  3364.  
  3365.  
  3366.  
  3367.  
  3368.  
  3369.  
  3370.                       -    52 -
  3371.  
  3372.  
  3373.      one net/rom node on different bands), we specify that we are to use  ax0
  3374.      to    send the packet.
  3375.  
  3376.     With net/rom, like IP, we don't    know exactly what route    a packet will
  3377.      take  to its destination.    We only    know the name of a neighbor which has
  3378.      indicated a willingness to    forward    that packet (of    course,    the  neighbor
  3379.      may  be the destination itself, but that's    unlikely in our    application).
  3380.      Net/rom sends the packet to the neighbor, with a network header specify-
  3381.      ing  our  callsign     and  that  of the ultimate destination    (in this case
  3382.      w9foo).
  3383.  
  3384.     We can use the netrom route add    command     to  establish    a  digipeater
  3385.      path to the neighbor.  For    example:
  3386.  
  3387.          netrom route add #foo w9foo ax0 192 w9rly wd9igi
  3388.  
  3389.      This will cause us    to use wd9igi as a  digipeater    in  establishing  our
  3390.      connection    to the net/rom node w9rly.
  3391.  
  3392.     To drop    the route to w9foo, you    would type
  3393.  
  3394.          netrom route drop w9foo w9rly ax0
  3395.  
  3396.     To see the contents of your routing table, you may type
  3397.  
  3398.          netrom route
  3399.  
  3400.      and to see    the routing entries for    an individual station you can type
  3401.  
  3402.          netrom route info <callsign>
  3403.  
  3404.      You may not use an    alias as an argument to    the netrom  route  info     com-
  3405.      mand.
  3406.  
  3407.     I can not stress enough    that "route add" and "netrom route  add"  are
  3408.      two  different  commands, with different purposes.     In general, you only
  3409.      need a "netrom route add" if you need to add a route to a    net/rom     node
  3410.      via  a  digipeater     path.     If you    find yourself using this command, ask
  3411.      yourself, "Why am I doing this?"  Many people  do    not  understand     that
  3412.      net/rom does automatic routing (well, sort    of :-)).
  3413.  
  3414.      5.6.  The Importance of the Routing Table
  3415.  
  3416.     The NET/ROM routing table is analogous to the IP routing  table:   if
  3417.      there  is nothing in it, your NET/ROM traffic will    not go out.  You must
  3418.      either manually enter a list of routes (perhaps via  your    autoexec.net)
  3419.      or     wait  to  receive routing broadcasts from your    neighbors before your
  3420.      NET/ROM traffic will leave    your station.
  3421.  
  3422.     If you go to send packets via NET/ROM and nothing  happens,  even  if
  3423.      you  have    trace mode on, make sure that the destination node is in your
  3424.      NET/ROM routing table.  If    sending    IP  traffic,  double  check  the  ARP
  3425.      table for an appropriate NET/ROM ARP entry    for the    destination node (see
  3426.      below for more information    on the use of the ARP table).  The ARP    table
  3427.  
  3428.  
  3429.  
  3430.  
  3431.  
  3432.  
  3433.  
  3434.  
  3435.  
  3436.                       -    53 -
  3437.  
  3438.  
  3439.      is    not used for NET/ROM transport routing.
  3440.  
  3441.      5.7.  Interfacing with NET/ROMs Using Your    Serial Port
  3442.  
  3443.     What if    you have a net/rom node    or nodes, and you'd  like  to  attach
  3444.      them  to  your  computer  via  their serial interfaces, and use net as a
  3445.      packet switch?  It's very easy:  you have to  attach  those  interfaces,
  3446.      using  the     "attach  asy"    command, but specifying    type "nrs" instead of
  3447.      "slip" or "kiss".    "nrs" is the net/rom serial framing  protocol,    which
  3448.      is     like  KISS,  but  uses    different framing characters and has an    8-bit
  3449.      checksum.
  3450.  
  3451.     When you attach    an nrs interface, it  can  be  used  for  passing  IP
  3452.      datagrams    or  AX.25  frames over serial lines or modems.    To use it for
  3453.      net/rom, you have to identify it to the netrom code just like any    other
  3454.      interface,    with the "netrom interface" command.
  3455.  
  3456.      5.8.  The Time to Live Initializer
  3457.  
  3458.     The "netrom ttl" command allows    setting    of the time-to-live  initial-
  3459.      izer  for    NET/ROM     datagrams.   I    recommend a value of 16    for most net-
  3460.      works.  Use more if you expect to go more than 16 hops.  The default  is
  3461.      64.
  3462.  
  3463.     The purpose of the ttl initializer is to prevent a packet  from     get-
  3464.      ting  caught  forever  in    routing     loops.     Every router who handles the
  3465.      packet decrements the ttl field of    the network datagram  before  sending
  3466.      it    on, and    when it    reaches    0 it is    discarded.
  3467.  
  3468.      5.9.  Using NET/ROM Support for IP
  3469.  
  3470.     Now you    know all the commands, but how do we actually use net/rom for
  3471.      IP    communications?     This takes two    steps:
  3472.  
  3473.     Step one:  update the routing table.  In all likelihood, you will use
  3474.      net/rom to    gateway    two IP subnets.     So, you'll probably want to identify
  3475.      a station on each end as a    gateway.  Let's    say we're  on  the  Milwaukee
  3476.      subnet,  and  we  want  to    talk to    someone    in Madison.  If    we're not the
  3477.      gateway, we just have a routing table entry like this:
  3478.  
  3479.          route add [44.92.0.0]/24 ax0 wg9ate-pc.ampr
  3480.  
  3481.      This specifies that wg9ate    should get all packets for the 44.92.0.x sub-
  3482.      net via interface ax0.
  3483.  
  3484.     Wg9ate has this    routing    table entry:
  3485.  
  3486.          route add [44.92.0.0]/24 netrom w9mad-pc.ampr
  3487.  
  3488.      (presuming    that w9mad is the Madison gateway).  Now, when the  IP    layer
  3489.      at     wg9ate    gets datagrams for Madison, it knows that they have to go via
  3490.      net/rom to    w9mad.    Notice that we don't specify a "real" interface, like
  3491.      ax1 or nr0, in the    route entry.  The net/rom network layer    will pick the
  3492.      right interface based on its net/rom routing tables.
  3493.  
  3494.  
  3495.  
  3496.  
  3497.  
  3498.  
  3499.  
  3500.  
  3501.  
  3502.                       -    54 -
  3503.  
  3504.  
  3505.     We're not done yet, though.  w9mad-pc.ampr is not an ax.25  callsign.
  3506.      The net/rom send routine called by    the IP layer needs to map from the IP
  3507.      address to    an ax.25 address.  It does this     via  a     manually  added  arp
  3508.      entry:
  3509.  
  3510.          arp add w9mad-pc.ampr netrom w9mad
  3511.  
  3512.      [We kind of fudged    by using the arp table for this    purpose, since    there
  3513.      is     no  way to do automatic address resolution for    net/rom, and arp mes-
  3514.      sages are never sent or received for net/rom nodes.   However,  the  arp
  3515.      table  does  contain  precisely  what  we    have  here:  mappings from IP
  3516.      addresses to callsigns, and it saved a lot    of code    to do it this way.]
  3517.  
  3518.      Notice also that no digipeaters are ever specified    in the arp entry  for
  3519.      a net/rom node.  Also, the    callsign to which we are mapping is the    final
  3520.      destination of the     packet,  not  the  non-destination  neighbor.     That
  3521.      neighbor will be picked based on the net/rom routing tables.
  3522.  
  3523.     So, as a summary, let's    look at    what happens to    a packet that reaches
  3524.      the IP layer on wg9ate, destined for Madison.  The    IP routing code    looks
  3525.      the destination IP    address    up in the table, and discovers that it should
  3526.      go     via  net/rom  to  w9mad-pc.ampr.   So,     it  passes the    packet to the
  3527.      net/rom send routine.  That routine uses  the  arp     table    to  translate
  3528.      w9mad-pc's     IP  address  to  the  callsign     "w9mad".  Then    it passes the
  3529.      packet to the net/rom routing code.  That code checks to see if the des-
  3530.      tination  callsign     (w9mad)  is  the same as that of any of its assigned
  3531.      net/rom interfaces.  Since    it isn't, it  puts  a  network    layer  header
  3532.      (a.k.a.  net/rom level 3 header) on it, and looks for w9mad in its    rout-
  3533.      ing tables.  Presumably,  it  finds  an  appropriate  neighbor  for  the
  3534.      packet, and sends in out via ax.25.  The net/rom network does the job of
  3535.      actually getting the packet to its    destination.
  3536.  
  3537.     At w9mad, the packet's protocol    ID causes it to    be sent    to  the     same
  3538.      net/rom  routing code that    handled    the outgoing packet from wg9ate    (run-
  3539.      ning on a different computer, of course).    Now the    destination  callsign
  3540.      matches, so the net/rom network layer header is stripped off, and packet
  3541.      is    passed up to the IP layer.  (Net/rom network  headers  don't  have  a
  3542.      protocol  ID  byte,  so  we  just    hope for the best.  If a net/rom node
  3543.      addresses a net/rom transport layer packet    to us, it  is  likely  to  be
  3544.      dropped by    IP for any of a    number of reasons.)
  3545.  
  3546.      5.10.  The    NET/ROM    Transport Layer
  3547.  
  3548.     NET/ROM    transport is the protocol used by NET/ROM node to communicate
  3549.      end-to-end.  When a user attaches to a NET/ROM via    AX.25, and asks    for a
  3550.      connect to    a node in the NODES list, his local NET/ROM tries to  open  a
  3551.      transport    connection  to the destination node over the NET/ROM network.
  3552.      NET/ROM transport packets are carried in NET/ROM network datagrams, just
  3553.      like IP datagrams.
  3554.  
  3555.     You shouldn't use NET/ROM transport when connecting to    other  TCP/IP
  3556.      stations.     TCP  is  a  much better protocol than NET/ROM transport, and
  3557.      makes better use of available bandwidth.  Also, BM     and  SMTP  are     more
  3558.      convenient     to  use  than a TCP/IP    station's mailbox facility.  However,
  3559.  
  3560.  
  3561.  
  3562.  
  3563.  
  3564.  
  3565.  
  3566.  
  3567.  
  3568.                       -    55 -
  3569.  
  3570.  
  3571.      for communicating with AX.25 users    via the    NET/ROM     network,  the    tran-
  3572.      sport  facilities    in  NET     will  work better (and    more easily) than the
  3573.      traditional method    of connecting to your local node via AX.25.
  3574.  
  3575.      5.11.  Connecting via NET/ROM Transport
  3576.  
  3577.     To connect to the node whose alias  is    FOO  and  whose     callsign  is
  3578.      W9FOO, you    can issue either of the    following two commands:
  3579.  
  3580.          netrom connect foo
  3581.  
  3582.          netrom connect w9foo
  3583.  
  3584.      If    foo:w9foo is  in  your    NET/ROM     routing  table,  your    station     will
  3585.      transmit  a  connect  request  to the appropriate neighbor    used to    reach
  3586.      w9foo.
  3587.  
  3588.     NET/ROM    transport sessions are very much like those for     AX.25.      You
  3589.      can  use  the  disconnect,    reset, kick, upload, and record    commands, and
  3590.      the session command to switch sessions.
  3591.  
  3592.      5.12.  Displaying the Status of NET/ROM Connections
  3593.  
  3594.     The command
  3595.  
  3596.          netrom status
  3597.  
  3598.      is    used to    display    the status of all  NET/ROM  connections,  which     will
  3599.      include  those used in keyboard sessions as well as ones attached to the
  3600.      mailbox.  For more    detailed information on    a session, you    can  use  the
  3601.      address of    the NET/ROM control block:
  3602.  
  3603.          netrom status <&nrcb>
  3604.  
  3605.      where <&nrcb> is the hex address given in the short form of the  command
  3606.      or    in the "session" display.
  3607.  
  3608.      5.13.  NET/ROM Transport Parameters
  3609.  
  3610.     The NET/ROM transport parameters may be    set with the various  NET/ROM
  3611.      subcommands.  Their meanings are listed below:
  3612.  
  3613.          acktime:         This is the ack delay timer,  similary  to     ax25
  3614.      t2.                  The default is 3000 ms.
  3615.  
  3616.          choketime:         The time to wait before breaking  a  send    choke
  3617.      condition.                       Choke   is  the  term  for
  3618.      NET/ROM flow control.
  3619.  
  3620.          irtt:         The initial round    trip  time  guess,  used  for
  3621.      timer setting.
  3622.  
  3623.          qlimit:         The maximum length    of the receive queue for chat
  3624.      sessions.                      This    is  similar  to     ax25
  3625.  
  3626.  
  3627.  
  3628.  
  3629.  
  3630.  
  3631.  
  3632.  
  3633.  
  3634.                       -    56 -
  3635.  
  3636.  
  3637.      window.
  3638.  
  3639.          retries:         Maximum retries on    connect, disconnect, and data
  3640.      frames.
  3641.  
  3642.          window:         Maximum sliding window size, negotiated down  at
  3643.      connect                     time.
  3644.  
  3645.  
  3646.      5.14.  The    Mailbox
  3647.  
  3648.     The AX.25 mailbox also accepts NET/ROM connections.   The  "mbox  on"
  3649.      and  "mbox     off"  commands     control whether the mailbox is    turned on for
  3650.      NET/ROM as    well as    AX.25, and the "mbox" command displays current    mail-
  3651.      box connects of both types.
  3652.  
  3653.     Many people have observed that the AX.25 mailbox requires the user to
  3654.      enter  a  carriage     return     to  bring up the banner and prompt.  This is
  3655.      because of    certain    defects    of that    protocol when it is used as the     link
  3656.      layer  for    several    different higher level protocols, and is unavoidable.
  3657.      (So stop asking, OK? :-))    The NET/ROM mailbox does not require the car-
  3658.      riage  return,  and will be activated as soon as the incoming connection
  3659.      is    completed.
  3660.  
  3661.      5.15.  Where to go    for More Information
  3662.  
  3663.     The paper  "Transmission  of  IP  Datagrams  over  NET/ROM  Networks"
  3664.      appeared  in  the    Seventh     ARRL Networking Conference papers, available
  3665.      from the ARRL.  In    it, I describe the more    technical details of how  the
  3666.      NET/ROM network support works.
  3667.  
  3668.     If you want to learn about NET/ROM, talk your local NET/ROM or TheNET
  3669.      operator  out of his or her manual.  If you want to learn more, read the
  3670.      source code.  That's about    it for sources,    since the  NET/ROM  protocols
  3671.      originated    in a commercial    product.
  3672.  
  3673.      5.16.  About the Code
  3674.  
  3675.     There has been a great deal of controversy about TheNET, a  no-charge
  3676.      NET/ROM  clone  for TNCs.    This is    not the    place to discuss the truth of
  3677.      the charges leveled by Software  2000  against  its  authors,  but     that
  3678.      situation requires    me to make the following statement:
  3679.  
  3680.     The NET/ROM transport support in NET.EXE was not taken    in  any     way,
  3681.      shape  or    form  from  NET/ROM  (whose source I have never    seen) or from
  3682.      TheNET.  The protocol code    is  based  on  protocol     6  from  Tanenbaum's
  3683.      excellent    book,  Computer     Networks, as a    moderately careful reading of
  3684.      both should show.    The source code    is freely distributed, so the curious
  3685.      reader  should have the opportunity to check this assertion if he or she
  3686.      so    desires.
  3687.  
  3688.     The smoothed round trip    time calculation, which    is not done in "real"
  3689.      NET/ROMs  (and  should be,    by the way -- they'd work a whole lot better)
  3690.      is    adapted    from that used by KA9Q in the TCP protocol in NET.  The    dicey
  3691.  
  3692.  
  3693.  
  3694.  
  3695.  
  3696.  
  3697.  
  3698.  
  3699.  
  3700.                       -    57 -
  3701.  
  3702.  
  3703.      business  of  adapting  it     to a sliding windows protocol with selective
  3704.      retransmission was    done by    me, all    alone, after my    cries for help on the
  3705.      tcp-group mailing list went unanswered :-).
  3706.  
  3707.     I have taken the precaution of copyrighting the    NET/ROM    code in     NET.
  3708.      It    may be freely distributed for non-commercial purposes, in whole    or in
  3709.      part, and may be used in other software packages such as BBS systems  if
  3710.      so     desired,  so  long  as     the copyright notice is not removed from the
  3711.      source files, and the program in which it is used displays    "NET/ROM code
  3712.      copyright 1989 by Dan Frank, W9NK"    when it    starts up.
  3713.  
  3714.     Any person who wishes to distribute the    code, or  anything  based  on
  3715.      the  code,     for  commercial  purposes  will find me very reasonable, but
  3716.      rather insistent about being compensated for the hours I've spent    work-
  3717.      ing on it.
  3718.  
  3719.  
  3720.  
  3721.  
  3722.  
  3723.  
  3724.  
  3725.  
  3726.  
  3727.  
  3728.  
  3729.  
  3730.  
  3731.  
  3732.  
  3733.  
  3734.  
  3735.  
  3736.  
  3737.  
  3738.  
  3739.  
  3740.  
  3741.  
  3742.  
  3743.  
  3744.  
  3745.  
  3746.  
  3747.  
  3748.  
  3749.  
  3750.  
  3751.  
  3752.  
  3753.  
  3754.  
  3755.  
  3756.  
  3757.  
  3758.  
  3759.  
  3760.  
  3761.  
  3762.  
  3763.  
  3764.  
  3765.  
  3766.                       -    58 -
  3767.  
  3768.  
  3769.      6.     Advanced Topics
  3770.  
  3771.      6.1.  The Finger Server
  3772.  
  3773.      < there will be finger docs here someday >
  3774.  
  3775.      6.2.  The GRAPES Multi-Port Digipeating Code
  3776.  
  3777.      The  multiport digipeating    code from GRAPES  will    allow  you  to    route
  3778.      frames  in     and out of LANs semi-automagically  based  on a table lookup
  3779.      maintained     by  the switch.
  3780.  
  3781.      To    enable multi-port digipeating, there are two tables that   you     must
  3782.      build  and     place    in  the    root directory.    They  are named     DIGILIST and
  3783.      EXLIST. DIGILIST contains the digis that  are directly   reachable     from
  3784.      your  switch.  The     file  is  a  simple  ASCII text  file containing the
  3785.      callsign of the digi and the  interface name   of    the  port  needed  to
  3786.      reach it. The port    name is     the  same name    you used in the    attach state-
  3787.      ment for that port. Additionally there  is    a special callsign "lan" that
  3788.      tells mulport which  port feeds your LAN or default port.
  3789.  
  3790.      The file would look something like    this:
  3791.  
  3792.      kd4nc-1 ax1      #    kd4nc-1    is a neighbor switch on    the high speed link
  3793.               #    attached to ax1    wb4gqx-1  ax3       #  wb4gqx-1    is  a
  3794.      neighbor  digi  on    145.01 (ax3) k4hal-1 ax2      #    k4hal-1    is a neighbor
  3795.      digi on 440 (ax2) lan  ax0        # lan is a special name    for  the  low
  3796.      speed  lan
  3797.               #    attached to the    switch and is the default port
  3798.               #    used when mycall is the    last call in the  digi
  3799.               #    string.
  3800.  
  3801.      The file EXLIST holds DESTINATION callsigns that do not obey  the rules.
  3802.      For  example,  a  user  station on    the high speed link. It     is formatted
  3803.      just like DIGILIST. To understand why this    file  may   be    necessary  we
  3804.      review the    rules mulport obeys.  First, mulport examines the digi string
  3805.      of    incoming frames. If it finds  it's  call in the    string and it is  not
  3806.      already   marked    as  repeated,  it  looks at the    next call in the digi
  3807.      string. If     a match  is  found between the     call  following  MYCALL   in
  3808.      the   digi    string and a call in DIGILIST, then the    frame is repeated out
  3809.      the port associated with that call    in DIGILIST. If    no  match  is    found
  3810.      then the frame is repeated    out the    port it    came in    on. If    MYCALL is the
  3811.      LAST call in the digi string then it repeats the  frame  out  the     port
  3812.      associated     with  "lan" in    the DIGILIST. So you see  that if  MYCALL  is
  3813.      the last or the only call    in  the     digi    string     the  frame  will  be
  3814.      repeated  out  the    lan port. This can cause a problem if the station you
  3815.      wish to connect is    only one digi hop away    and is    not  on     the lan fre-
  3816.      quency. The  EXLIST  handles  this     case. Mulport    will look at the DES-
  3817.      TINATION call if MYCALL is    the  last or only call in the digi string. If
  3818.      a    match  is  found with a     call in EXLIST    then the port associated with
  3819.      that DESTINATION call  is used  to    repeat the frame. EXLIST  is only for
  3820.      stations  who  would normally be expected to be on    the lan    side  but are
  3821.      operating off some    other port  instead.  An  example  might  be  a     PBBS
  3822.      operating on the trunk to serve more than one lan.
  3823.  
  3824.  
  3825.  
  3826.  
  3827.  
  3828.  
  3829.  
  3830.  
  3831.  
  3832.                       -    59 -
  3833.  
  3834.  
  3835.      6.3.  Multiple Serial Ports on One    Interrupt
  3836.  
  3837.      Thanks to effort from Dan Frank, W9NK, this version of net    supports  the
  3838.      idea  of  multiple     serial    ports all sharing a common hardware interrupt
  3839.      line. The original    motivation for this was    to support the IBM PS/2     fam-
  3840.      ily,  but it turns    out to be very helpful with a variety of PC/AT inter-
  3841.      face cards    as well.
  3842.  
  3843.      There are no new commands,    and  existing  autoexecs  don't     need  to  be
  3844.      changed.  All  you    have to    do to share interrupts is simply use the same
  3845.      interrupt in more than one    attach line. This applies *only* to asy     dev-
  3846.      ices. An interrupt    may not    be shared between, e.g., an ethernet card and
  3847.      a serial port.
  3848.  
  3849.      The code has been tested on an IBM    PS/2 Model 70  with  the  dual    async
  3850.      adaptor.  Any card    that logical-ORs the interrupt lines from the various
  3851.      UARTS should work.
  3852.  
  3853.      Interrupt sharing at the bus level    does not work on the AT    bus, but does
  3854.      work  on  the  Micro  Channel.  The PS/2 series uses interrupt 4 for the
  3855.      motherboard async port, then interrupt 3  for  all     bus-attached  serial
  3856.      ports.
  3857.  
  3858.      The code is  believed  to    work  with  both  level-sensitive  and    edge-
  3859.      triggered interrupts, but hasn't been fully tested.
  3860.  
  3861.      As    an example, the    Quadram    Quadport AT with the add-on daughtercard  can
  3862.      handle up to five serial ports sharing the    same interrupt,    and up to two
  3863.      cards may be supported in a PC, making a total of more serial ports than
  3864.      a poor little PC should be    asked to handle...
  3865.  
  3866.  
  3867.  
  3868.  
  3869.  
  3870.  
  3871.  
  3872.  
  3873.  
  3874.  
  3875.  
  3876.  
  3877.  
  3878.  
  3879.  
  3880.  
  3881.  
  3882.  
  3883.  
  3884.  
  3885.  
  3886.  
  3887.  
  3888.  
  3889.  
  3890.  
  3891.  
  3892.  
  3893.  
  3894.  
  3895.  
  3896.  
  3897.  
  3898.                       -    60 -
  3899.  
  3900.  
  3901.      7.     NET Command Reference
  3902.  
  3903.      7.1.  Startup
  3904.  
  3905.      When NET.EXE is executed without arguments, it  attempts  to  open      the
  3906.      file  "AUTOEXEC.NET"  in  the root    directory of the current drive.    If it
  3907.      exists, it    is read    and executed as    though its contents were typed on the
  3908.      console  as   commands.  This feature is useful for setting the local IP
  3909.      address and host name, initializing the IP    routing    table,    and  starting
  3910.      the  various  Internet  services.     If   NET.EXE    is  invoked  with  an
  3911.      argument, it is taken to be the name of an    alternate startup file;    it is
  3912.      read instead of AUTOEXEC.NET.
  3913.  
  3914.      7.2.  Console Mode
  3915.  
  3916.      The console may be    in one of two  modes:  command    mode   and   converse
  3917.      mode.  In    command     mode,    the prompt "net>" is displayed and any of the
  3918.      commands described    in the next section may    be entered. In converse    mode,
  3919.      keyboard input is    processed  according  to the "current session",    which
  3920.      may be either a Telnet, FTP, or AX.25 connection. In a telnet  or    AX.25
  3921.      session,  keyboard    input is sent  to the  remote  system  and any output
  3922.      from the remote system is displayed on the    console. In an    FTP  session,
  3923.      keyboard  input is    first examined to see if it  is    a  known  local     com-
  3924.      mand; if so it is executed    locally. If not, it is    "passed     through"  to
  3925.      the remote    FTP server. (See  the  section    titled    "FTP  Subcommands").
  3926.  
  3927.      The keyboard also has "cooked" and    "raw" states. In cooked     state,    input
  3928.      is     line-at-a-time;  the user may use the line editing characters ^U, ^R
  3929.      and backspace to erase the    line, redisplay    the  line   and      erase      the
  3930.      last  character, respectively. Hitting either return or line feed passes
  3931.      the complete line up to the application. In raw mode, each    character  is
  3932.      immediately  passed  to  the application as it is typed. The keyboard is
  3933.      always in cooked state in command mode. It    is also     cooked     in  converse
  3934.      mode  on  an  AX25     or  FTP  session.  In a Telnet    session    it depends on
  3935.      whether the remote    end has    issued (and the    local end has  accepted)  the
  3936.      Telnet "WILL ECHO"    option.    (See the "echo"    command).
  3937.  
  3938.      On    the IBM-PC, the    user may escape    back to     command  mode     by   hitting
  3939.      the   F10    key.  On the HP    Portable and Portable Plus, which have only 8
  3940.      function keys, F8 is used instead.     On  other  systems,  the  user     must
  3941.      enter  the     "escape"  character,  which is    by default control-] (hex 1d,
  3942.      ASCII GS).    (Note that this    is distinct from  the  ASCII   character   of
  3943.      the  same    name).    The escape character can be changed (see the "escape"
  3944.      command).
  3945.  
  3946.      7.3.  Commands
  3947.  
  3948.      This section describes each of the    commands recognized while in  command
  3949.      mode.   Note   that  certain  FTP subcommands, e.g., put, get, dir, etc,
  3950.      are recognized only in converse mode with the appropriate    FTP  session;
  3951.      they   are      not  recognized  while in command mode. The notation "<hos-
  3952.      tid>" denotes a host or gateway, which may    be specified in     one  of  two
  3953.      ways:  as    a  symbolic name  listed  in the  file    "/hosts.net", or as a
  3954.      numeric IP    address    in dotted  decimal  notation  enclosed    by  brackets,
  3955.  
  3956.  
  3957.  
  3958.  
  3959.  
  3960.  
  3961.  
  3962.  
  3963.  
  3964.                       -    61 -
  3965.  
  3966.  
  3967.      e.g.,  [44.0.0.1].     When  domain  server  support    is  added, ARPA-style
  3968.      domain  names  (e.g., ka9q.ampr) will  also  be  accepted    if  a  domain
  3969.      server is available on the    network    to resolve them    into IP    addresses.
  3970.  
  3971.      7.3.1.  <cr>
  3972.  
  3973.      Entering a    carriage return    (empty line) while in command mode  puts  you
  3974.      in     converse   mode  with    the  current  session. If there    is no current
  3975.      session, net remains in command mode.
  3976.  
  3977.      7.3.2.  !
  3978.  
  3979.      An    alias for the "shell" command.
  3980.  
  3981.      7.3.3.  #
  3982.  
  3983.      Commands starting with the    hash mark (#) are ignored. This      is   mainly
  3984.      useful for    comments in the    AUTOEXEC.NET file.
  3985.  
  3986.      7.3.4.  arp
  3987.  
  3988.      With no arguments,    displays the Address Resolution    Protocol  table     that
  3989.      maps  IP  addresses  to  their  subnet  (link)  addresses on subnetworks
  3990.      capable of    broadcasting. For each    IP  address  entry  the     subnet     type
  3991.      (e.g.,  Ethernet,    AX.25),     subnet     address  and time to  expiration  is
  3992.      shown. If the link    address     is  currently    unknown,  the  number  of  IP
  3993.      datagrams awaiting    resolution is also shown.
  3994.  
  3995.      7.3.4.1.  arp add <hostid>    ether|ax25|netrom <ether addr|callsign>
  3996.  
  3997.      The add subcommand    allows manual addition of address resolution  entries
  3998.      into  the table.  This is useful for "hard-wiring"    digipeater paths, and
  3999.      other paths that are not directly resolvable.
  4000.  
  4001.      7.3.4.2.  arp drop    <hostid> ether|ax25|netrom
  4002.  
  4003.      The drop subcommand allows    removal    of entries from    the table.
  4004.  
  4005.      7.3.4.3.  arp publish <hostid> ether|ax25|netrom <ether addr|callsign>
  4006.  
  4007.      The publish subcommand allows you to respond to  arp  queries  for     some
  4008.      other  host.   This  is commonly referred to as "proxy arp", and is con-
  4009.      sidered a fairly dangerous    tool.  The basic idea is that if you have two
  4010.      machines,    one  of    which is on the    air with a TNC,    and the    second one of
  4011.      which is connected    to the first with a slip link,    you  might  want  the
  4012.      first  machine to publish it's own    AX.25 address as the right answer for
  4013.      arp queries addressing the    second machine.     This way, the    rest  of  the
  4014.      world  doesn't know the second machine isn't really on the    air.  Use arp
  4015.      publish with caution.
  4016.  
  4017.      7.3.5.  attach
  4018.  
  4019.      attach <hwtype> <I/O  addr>  <vector>  <mode>  <label>  <bufsize>    <mtu>
  4020.      [<speed>]"
  4021.  
  4022.  
  4023.  
  4024.  
  4025.  
  4026.  
  4027.  
  4028.  
  4029.  
  4030.                       -    62 -
  4031.  
  4032.  
  4033.      Configure and attach a hardware interface to the system.
  4034.  
  4035.      <hw type> represents the kind of I/O device  that    is  being   attached.
  4036.      The following types are some that are supported:
  4037.  
  4038.      packet  FTP, Inc.,    compatible Packet Driver Interface 3c500   3Com    3C500
  4039.      or     3C501    Ethernet interface asy       Standard PC asynchronous interface
  4040.      using the National    8250 hapn    Hamilton Amateur Packet Network  adapter
  4041.      board (Intel 8273)    eagle    Eagle Computer card (Zilog 8530) pc100     PAC-
  4042.      COMM PC-100 (Zilog    8530)
  4043.  
  4044.      These last    two interfaces    are  still  under  development;     driver     code
  4045.      included in this package may or may not work.
  4046.  
  4047.      <I/O address> is the base address of the control registers    for the     dev-
  4048.      ice.
  4049.  
  4050.      <vector> is the interrupt vector number.    Both  the  address  and      the
  4051.      vector  must  be in hexadecimal. (You may put "0x"    in front of these two
  4052.      values if you wish, but note that they will be interpreted    in  hex     even
  4053.      if    you don't use it).
  4054.  
  4055.      <mode> controls how  IP  datagrams     are  to  be  encapsulated   in      the
  4056.      device's link level protocol; i.e., it selects among several link proto-
  4057.      cols that may be available.  The choices here depend on  the  interface;
  4058.      at     present,  the    3c500 interface    only supports mode "arpa", which uses
  4059.      standard ARPA-style encapsula- tion.  (In the  future,  "802"  may     mean
  4060.      "use  802.3-style    encapsulation").   Two modes for the "asy" device are
  4061.      currently supported:
  4062.  
  4063.      slip    Encapsulates IP datagrams directly    in SLIP    frames without a link
  4064.          header. This is for operation on  point-to-point  lines  and  is
  4065.          compatible    with 4.2BSD UNIX SLIP).
  4066.  
  4067.      ax25    Similar to    slip, except that an AX.25 header and a    KISS TNC
  4068.          control header are    added to the front  of    the  datagram  before
  4069.          SLIP    encoding.       Either    UI       (connectionless)    or   I
  4070.          (connection-oriented)  AX.25  frames  can    be  used;   see      the
  4071.          "mode" command for    details.
  4072.  
  4073.      The Address Resolution Protocol (ARP) maps    IP to Ethernet    addresses  on
  4074.      Ethernet  controllers and to AX.25    addresses on "asy" lines operating in
  4075.      "ax25" mode.
  4076.  
  4077.      <label> gives the name by which the  interface  will  be  known  to  the
  4078.      various commands, such as "connect", "route" and "trace".
  4079.  
  4080.      For asynchronous ports, <bufsize> specifies the size of the ring  buffer
  4081.      in     bytes     to  be    statically allocated to    the receiver; incoming bursts
  4082.      larger than this may (but not necessarily)    cause data to be  lost.      For
  4083.      Ethernet,    <bufsize>  specifies   how  many PACKETS may be    queued on the
  4084.      receive queue at one time;    if this    limit is exceeded,  further  received
  4085.      packets  will  be    discarded.   This  is useful  to  prevent  the system
  4086.      from running out of memory    should another node suddenly develop  a     case
  4087.  
  4088.  
  4089.  
  4090.  
  4091.  
  4092.  
  4093.  
  4094.  
  4095.  
  4096.                       -    63 -
  4097.  
  4098.  
  4099.      of    diarrhea.
  4100.  
  4101.      <mtu> is the Maximum  Transmission     Unit  size,  in  bytes.    Datagrams
  4102.      larger  than   this   limit   will     be  fragmented     at the    IP layer into
  4103.      smaller pieces. For AX.25 UI frames, this limits the size of the  infor-
  4104.      mation field.  For     AX.25    I frames,  however, the    ax25 paclen parameter
  4105.      is    also relevant.    If the datagram    or  fragment  is  still     larger     than
  4106.      paclen,  it  is  also fragmented  at  the    AX.25 level  (as  opposed  to
  4107.      the  IP  level)  before transmission.  (See the  "ax25  paclen"  command
  4108.      for further information).
  4109.  
  4110.      <speed> is    needed only for     an  "asy"  line;  the    controller  will   be
  4111.      initial- ized to the given    speed.
  4112.  
  4113.      Examples:
  4114.  
  4115.       #    Attach a 3Com Ethernet controller using    the standard 3Com address and
  4116.       #    vector (i.e., as it comes out of the box) to use ARPA-standard
  4117.       #    encapsulation.    The receive queue is limited to    5 packets, and
  4118.       #    outgoing packets larger    than 1500 bytes    will be    fragmented
  4119.  
  4120.      attach 3c500 0x300    3 arpa ec0 5 1500
  4121.  
  4122.       #    Attach the PC asynch card normally known as "com1" (the    first
  4123.       #    controller) to operate in point-to-point slip mode at 9600 baud,
  4124.       #    calling    it "sl0".  A 1024 byte receiver    ring buffer is allocated.
  4125.       #    Outgoing packets larger    than 256 bytes are fragmented.
  4126.  
  4127.      attach asy    0x3f8 4    slip sl0 1024 256 9600
  4128.  
  4129.       #    Attach the secondary PC    asynch card ("com2") to    operate    in AX.25
  4130.       #    mode with an MTU of 576    bytes at 9600 baud with    a KISS TNC,
  4131.       #    calling    it "ax0".  By default, IP datagrams are     sent  in  UI  frames
  4132.      attach asy    0x2f8 3    ax25 ax0 1024 576 9600
  4133.  
  4134.      (Note that    you cannot use the second asynch controller  ("com2")  and  a
  4135.      3Com  Ethernet   card  with standard addressing at    the same time because
  4136.      they both use interrupt vector 3).
  4137.  
  4138.      7.3.5.1.  HP Portable Specifics For the unwary, the  following  are  the
  4139.      correct I/O address values    for the    HP Portable and    Portable Plus... note
  4140.      that the <vector> is unimportant, but must     be  included  for  the     line
  4141.      parsing to    work correctly.
  4142.  
  4143.      HP     Portable  Plus     Serial      Port      0x44     HP   Portable     Plus    Modem
  4144.      Port     0xa4 HP Portable               0xa4
  4145.  
  4146.  
  4147.      7.3.5.2.  SLIP Modem Dialing
  4148.  
  4149.      An    extension to the attach    command    allows the syntax:
  4150.  
  4151.     attach <hw type> <I/O address> <vector>    <mode> <label> <bufsiz>    <mtu>
  4152.            [<speed>] [[optional '-'    for  debug]  <send>  <expect>  <send>
  4153.  
  4154.  
  4155.  
  4156.  
  4157.  
  4158.  
  4159.  
  4160.  
  4161.  
  4162.                       -    64 -
  4163.  
  4164.  
  4165.      [...]]
  4166.  
  4167.      for slip connections only.    The send/expect    sequences allow    you to dial a
  4168.      modem  on    the  slip  port, and negotiate a remote    login to setup a slip
  4169.      link.
  4170.  
  4171.              - - desend    carriagedreturn            - N    s-ndsendwNULL
  4172.            E  -     send control-D               -   send     space     (not
  4173.      really  needed as the                     cmdparse routine
  4174.      allows quoting)           \  -     send backslash
  4175.  
  4176.      Note that an expect does not have to follow the last send.     Those    fami-
  4177.      liar  with    UUCP will recognize the    expect/send paradigm as    being similar
  4178.      to    that used in the L.sys or Systems file.
  4179.  
  4180.      7.3.6.  ax25
  4181.  
  4182.      7.3.6.1.  ax25 digipeat [on|off]
  4183.  
  4184.      Controls whether AX.25 packets addressed to  this    station     as  a    digi-
  4185.      peater will be repeated.
  4186.  
  4187.      7.3.6.2.  ax25 heard [on|off]
  4188.  
  4189.      Works like    the 'mheard' function in many  TNC's.  The  command  with  no
  4190.      parameter    dumps the list of callsigns heard, with    an option you control
  4191.      whether the list is updated or not.
  4192.  
  4193.      7.3.6.3.  ax25 maxframe [<val]>]
  4194.  
  4195.      Establishes the maximum number of frames  that   will   be     allowed   to
  4196.      remain  unacknowledged at one time    on new AX.25 connections. This number
  4197.      cannot be greater than 7.
  4198.  
  4199.      7.3.6.4.  ax25 mycall [<call>]
  4200.  
  4201.      Display or    set the    local  AX.25  address.      The    standard  format   is
  4202.      used,   e.g.,  KA9Q-0 or WB6RQN-5.    This command must be given before any
  4203.      attach command using AX.25    mode are given.
  4204.  
  4205.      7.3.6.5.  ax25 bbscall [<call>]
  4206.  
  4207.      Same as mycall, but sets the callsign of the W2XO BBS.  This  subcommand
  4208.      is    only accessible    when you compile net with XOBBS    and SID2 defined. The
  4209.      default is    to use a single    callsign/ssid for both NET and the PBBS.
  4210.  
  4211.      7.3.6.6.  ax25 paclen [<val>]
  4212.  
  4213.      Limits the    size of     I-fields  on  new  AX.25  connections.      Note     that
  4214.      if    IP datagrams or    fragments larger than this are transmitted, they will
  4215.      be    transparently fragmented at the    AX.25 level, sent as  a      series   of
  4216.      I    frames,      and  reassembled  back into a    complete IP datagram or    frag-
  4217.      ment at the other end of the link.    This parameter should  be  less     than
  4218.  
  4219.  
  4220.  
  4221.  
  4222.  
  4223.  
  4224.  
  4225.  
  4226.  
  4227.                       -    65 -
  4228.  
  4229.  
  4230.      the MTU of    the associated interface.
  4231.  
  4232.      7.3.6.7.  ax25 pthresh [<val>]
  4233.  
  4234.      Sets threshold for    transmit without <cr>.
  4235.  
  4236.      7.3.6.8.  ax25 reset <axcb>
  4237.  
  4238.      Deletes the AX.25 connection control block    at the    specified address.
  4239.  
  4240.      7.3.6.9.  ax25 retry [<val>]
  4241.  
  4242.      Limits the    number of successive unsuccessful retransmission attempts  on
  4243.      new   AX.25  connections.    If  this  limit     is exceeded, link re- estab-
  4244.      lishment is attempted. If this fails "retry" times, then    the   connec-
  4245.      tion is abandoned and all queued data is deleted.
  4246.  
  4247.      7.3.6.10.    ax25 status [<axcb>]
  4248.  
  4249.      Without an    argument, displays a one-line summary of  each AX.25  control
  4250.      block.    If   the      address  of  a  particular  control block is speci-
  4251.      fied, the contents    of that    control    block  are  dumped  in    more  detail.
  4252.      Note that the send    queue units are    frames,    while the receive queue    units
  4253.      are bytes.
  4254.  
  4255.      7.3.6.11.    ax25 t1|t2|t3 [<val>]
  4256.  
  4257.      Display  or  set  the  AX.25 timers  to  be used for new connections. T1
  4258.      is     the  retransmission timer, T2 is the acknowledgement delay timer and
  4259.      T3    is the idle "keep alive" timer.     Values    are in seconds.
  4260.  
  4261.      7.3.6.12.    ax25 window [<val>]
  4262.  
  4263.      Sets the number of    bytes that can    be  pending  on      an   AX.25  receive
  4264.      queue   beyond   which  I frames will be answered with RNR    (Receiver Not
  4265.      Ready) responses.    This presently applies only to suspended  interactive
  4266.      AX.25 sessions, since incoming IP datagrams are always processed immedi-
  4267.      ately and not allowed to remain on    the receive queue.
  4268.  
  4269.      7.3.7.  close [<session #>]
  4270.  
  4271.      On    an AX.25 session, this command initiates a  disconnect.     On a FTP  or
  4272.      Telnet  session,  this  command sends a FIN (i.e.,    initiates a close) on
  4273.      the session's TCP connection.  This is  an     alternative  to  asking  the
  4274.      remote server  to initiate    a close    ("QUIT"    to FTP,    or the logout command
  4275.      appropriate for the remote    system in the case of Telnet).     When  either
  4276.      FTP or Telnet  sees the  incoming    half  of  a  TCP connection close, it
  4277.      automatically responds by closing the outgoing half of  the  connection.
  4278.      Close  is    more  graceful    than  the "reset"  command,  in     that  it  is
  4279.      less  likely to leave the remote TCP in a "half-open" state.
  4280.  
  4281.      7.3.8.  connect <interface> <callsign> [<digipeater> ... ]
  4282.  
  4283.      Initiates a "vanilla" AX.25 session   to    the   specified      call     sign
  4284.  
  4285.  
  4286.  
  4287.  
  4288.  
  4289.  
  4290.  
  4291.  
  4292.  
  4293.                       -    66 -
  4294.  
  4295.  
  4296.      using  the     specified  interface.    Up  to    7 optional digipeaters may be
  4297.      given; note that the word    "via"  is  NOT    needed.     Data  sent  on     this
  4298.      session  goes out in conventional AX.25 packets with no upper layer pro-
  4299.      tocol.  The de-facto presentation standard    format is   used,   in     that
  4300.      each  packet holds    one line of text, terminated by    a carriage return.  A
  4301.      single AX.25 connection may be used for both  terminal-to-terminal      and
  4302.      IP      traffic,  with  the two types    of data    being automatically separated
  4303.      by    their AX.25 Level 3 Protocol IDs.
  4304.  
  4305.      7.3.9.  dir [<dirname>]
  4306.  
  4307.      List the contents of the specified    directory on  the   console.   If  no
  4308.      argument is given,    the current directory is listed.
  4309.  
  4310.      7.3.10.  disconnect [<session #>]
  4311.  
  4312.      An    alias for the "close" command (for the benefit    of AX.25 users).
  4313.  
  4314.      7.3.11.  echo [accept|refuse]
  4315.  
  4316.      Displays or changes the flag controlling client  Telnet's response    to  a
  4317.      remote WILL ECHO offer.
  4318.  
  4319.      The Telnet    presentation protocol specifies    that  in  the  absence    of  a
  4320.      negotiated     agreement   to      the    contrary,  neither  end     echoes     data
  4321.      received from the other.  In this mode, a Telnet client  session  echoes
  4322.      keyboard  input  locally  and  noth- ing  is  actually sent until a car-
  4323.      riage return is typed. Local line editing is also    performed:  backspace
  4324.      deletes  the last character  typed,  while     control-U deletes the entire
  4325.      line.
  4326.  
  4327.      When communicating    from keyboard to keyboard  the    standard  local     echo
  4328.      mode  is used,  so    the setting of this parameter has no effect. However,
  4329.      many timeshar- ing    systems    (e.g., UNIX) prefer to do their     own  echoing
  4330.      of     typed    input.     (This    makes  screen editors work right, among    other
  4331.      things). Such systems send    a Tel- net WILL    ECHO offer  immediately     upon
  4332.      receiving    an  incoming  Telnet  connection request. If "echo accept" is
  4333.      in    effect,    a client Telnet    session    will automati- cally return a DO ECHO
  4334.      response. In this mode, local echoing  and     editing  is turned  off  and
  4335.      each  key    stroke    is sent    immediately (subject to     the  Nagle  tinygram
  4336.      algorithm in TCP).     While this mode is just fine across an     Ethernet, it
  4337.      is     clearly  inefficient  and  painful across  slow  paths     like  packet
  4338.      radio  channels.  Specifying  "echo refuse" causes    an incoming WILL ECHO
  4339.      offer  to    be answered with a  DONT  ECHO;     the  client  Telnet  session
  4340.      remains  in  the  local  echo mode.  Sessions already in the remote echo
  4341.      mode are unaffected. (Note:  Berke- ley  Unix has a bug in    that it     will
  4342.      still  echo input even after the client has refused the WILL ECHO offer.
  4343.      To    get  around  this  problem,  enter  the     "stty -echo" command to  the
  4344.      shell once    you have logged    in.)
  4345.  
  4346.      7.3.12.  eol [unix|standard]
  4347.  
  4348.      Displays or changes Telnet's end-of-line behavior when in    remote     echo
  4349.      mode.   In      standard   mode,  each  key  is  sent     as-is.    In unix    mode,
  4350.  
  4351.  
  4352.  
  4353.  
  4354.  
  4355.  
  4356.  
  4357.  
  4358.  
  4359.                       -    67 -
  4360.  
  4361.  
  4362.      carriage returns are translated to    line  feeds.   This  command  is  not
  4363.      necessary    with   all   UNIX   sys- tems;    use  it    only  when  you     find
  4364.      that a particular    system    responds  to  line  feeds  but    not  carriage
  4365.      returns.    Only  Sun UNIX release 3.2  seems  to  exhibit this behavior;
  4366.      later releases are    fixed.
  4367.  
  4368.      7.3.13.  escape <char>
  4369.  
  4370.      Without arguments,    displays the current command-mode escape character in
  4371.      hex.   If     given     an   argument,     the  first character becomes the new
  4372.      escape character.    (This command is not provided on the IBM-PC;  on  the
  4373.      PC,  the  escape  char  is    always F10.)
  4374.  
  4375.      7.3.14.  etherstat
  4376.  
  4377.      Display 3-Com Ethernet controller statistics (if configured).
  4378.  
  4379.      7.3.15.  exit
  4380.  
  4381.      Exit the "net" program and    return to MS-DOS (or CP/M).
  4382.  
  4383.      7.3.16.  finger
  4384.  
  4385.      For information on    the Finger subsystem,  see  the     information  in  the
  4386.      advanced topics section of    this manual.
  4387.  
  4388.      7.3.17.  ftp <hostid>
  4389.  
  4390.      Open an FTP control channel to the    specified  remote  host      and    enter
  4391.      converse mode  on    the  new  session.
  4392.  
  4393.      When in converse mode with    an FTP server, everything typed    on the     con-
  4394.      sole   is    first  examined     to  see if it is a locally-known command. If
  4395.      not, the line is passed intact to the remote server on the    control    chan-
  4396.      nel.   If    it  is one of the following commands, however, it is executed
  4397.      locally. (Note that this generally    involves other commands    being sent to
  4398.      the  remote  server on the     control  channel.) When  actively  transfer-
  4399.      ring  a  file,  the only acceptable command is "abort"; all  other     com-
  4400.      mands  will  result  in  an  error     message.  Responses  from the remote
  4401.      server are    displayed directly on the screen.
  4402.  
  4403.      7.3.17.1.    abort
  4404.  
  4405.      Aborts a get, put or dir operation    in progress. When receiving a    file,
  4406.      abort  simply  resets the data connection;    the next incoming data packet
  4407.      will generate a TCP RST (reset) in    response which will clear the  remote
  4408.      server.   When   send-  ing a file, abort sends a premature end-of-file.
  4409.      Note that in both cases abort will    leave a    partial    copy of    the  file  on
  4410.      the  destination  machine,      which      must    be  removed manually if    it is
  4411.      unwanted. Abort is    valid only when    a transfer is in progress.
  4412.  
  4413.      7.3.17.2.    dir [<file>|<directory>    [<localfile>]]
  4414.  
  4415.      Without arguments,    "dir" requests that a full directory listing  of  the
  4416.  
  4417.  
  4418.  
  4419.  
  4420.  
  4421.  
  4422.  
  4423.  
  4424.  
  4425.                       -    68 -
  4426.  
  4427.  
  4428.      remote server's current directory be sent to the terminal.     If one    argu-
  4429.      ment is given, this is passed along in the    LIST command; this can    be  a
  4430.      specific file or  sub- directory  that  is    meaningful to the remote file
  4431.      system. If    two arguments are given, the second is    taken  as  the    local
  4432.      file  into     which    the  directory    listing    should    be  put     (instead  of
  4433.      being sent    to the console).  The PORT command is used  before  the     LIST
  4434.      command is    sent.
  4435.  
  4436.      7.3.17.3.    get <remote_file> [<local_file>]
  4437.  
  4438.      Asks the remote server to send the    file specified in the first argument.
  4439.      The  second   argument,  if  given,  will be the name of the file on the
  4440.      local machine; otherwise it will have the same name  as  on  the  remote
  4441.      machine.  The  PORT  and RETR commands are    sent on    the control channel.
  4442.  
  4443.      7.3.17.4.    ls [<file>|<directory> [<localfile>]]
  4444.  
  4445.      ls    is identical to    the "dir" command except that the "NLST"  command  is
  4446.      sent  to the  server  instead  of    the  "LIST"  command. This results in
  4447.      an    abbreviated directory listing, i.e., one showing only the file    names
  4448.      themselves     without any other information.
  4449.  
  4450.      7.3.17.5.    mkdir <remote_directory>
  4451.  
  4452.      Creates a directory on the    remote machine.
  4453.  
  4454.      7.3.17.6.    put <local_file> [<remote_file>]
  4455.  
  4456.      Asks the remote server to accept data, creating the file named  in      the
  4457.      first argument.  The  second argument, if given, will be the name of the
  4458.      file on the remote    machine; otherwise it will have    the same name  as  on
  4459.      the  local     machine.  The PORT and    STOR commands are sent on the control
  4460.      channel.
  4461.  
  4462.      7.3.17.7.    rmdir <remote_directory>
  4463.  
  4464.      Deletes a directory on the    remote machine.
  4465.  
  4466.      7.3.17.8.    type [a|i|l<bytesize>]
  4467.  
  4468.      Tells both    the local client and remote server the type of file  that  is
  4469.      to     be transferred.  The default is 'a', which means ASCII    (i.e., a text
  4470.      file).  Type length  lines      of   text   in  ASCII     separated  by    cr/lf
  4471.      sequences;     in  IMAGE mode, files are sent    exactly    as they    appear in the
  4472.      file system.  ASCII  mode    should be  used     whenever  transferring     text
  4473.      between dissimilar    systems    (e.g., UNIX and    MS-DOS)    because    of their dif-
  4474.      ferent end-of-line    and/or end-of-file conventions.     When exchanging text
  4475.      files between machines of the same    type, either mode will work but    IMAGE
  4476.      mode may be somewhat faster.  Naturally,  when  exchanging      raw  binary
  4477.      files  (executables,  compressed archives,    etc) IMAGE mode    must be    used.
  4478.      Type 'l' (logical byte size) is used when exchanging binary  files     with
  4479.      remote  servers   having    oddball      word sizes (e.g., DECSYSTEM-10s and
  4480.      20s). Locally it works exactly like IMAGE,    except that it    notifies  the
  4481.      remote  system  how  large    the  byte size is. <bytesize> is typically 8.
  4482.  
  4483.  
  4484.  
  4485.  
  4486.  
  4487.  
  4488.  
  4489.  
  4490.  
  4491.                       -    69 -
  4492.  
  4493.  
  4494.      The type command sets the local transfer mode  and     generates  the     TYPE
  4495.      command on    the control channel.
  4496.  
  4497.      7.3.18.  help
  4498.  
  4499.      Display a brief summary of    top-level commands.
  4500.  
  4501.      7.3.19.  hostname [<name>]
  4502.  
  4503.      Displays or sets the local    host's name (an    ASCII string such  as  "ka9q-
  4504.      pc",  NOT    an  IP address).  Currently this is used only in the greeting
  4505.      messages from the SMTP (mail) and FTP (file transfer) servers.
  4506.  
  4507.      7.3.20.  log [stop|<file>]
  4508.  
  4509.      Without  arguments,  indicates  whether  server   sessions      are    being
  4510.      logged.   If "stop" is given as the argument, logging is terminated (the
  4511.      servers themselves    are unaffected). If a file name    is given as an    argu-
  4512.      ment,  server  session  log entries will be appended to it.
  4513.  
  4514.      7.3.21.  ip
  4515.  
  4516.      7.3.21.1.    ip address [<hostid>]
  4517.  
  4518.      Displays or sets the local    IP address.
  4519.  
  4520.      7.3.21.2.    ip status
  4521.  
  4522.      Displays Internet    Protocol  (IP)    statistics,  such  as  total   packet
  4523.      counts   and error     counters of various types.  Also displays statistics
  4524.      about the Internet    Control    Message    Protocol (ICMP), including the number
  4525.      of    ICMP messages of each type sent    or received.
  4526.  
  4527.      7.3.21.3.    ip ttl [<val>]
  4528.  
  4529.      Displays or sets the default time-to-live value placed  in     each  outgo-
  4530.      ing   IP  datagram.  This    limits the number of switch hops the datagram
  4531.      will be allowed to    take. The idea is  to  bound  the  lifetime  of      the
  4532.      packet   should  it  become caught     in a routing loop, so make the    value
  4533.      somewhat larger than the diameter of the network.
  4534.  
  4535.      7.3.22.  memstat
  4536.  
  4537.      Displays the internal free    memory list in the storage allocator.
  4538.  
  4539.      7.3.23.  mode <interface> [vc|datagram]
  4540.  
  4541.      Controls the default transmission mode on the specified   AX.25   inter-
  4542.      face.   In     "datagram"   mode,  IP     packets are encapsulated in AX.25 UI
  4543.      frames and    transmit- ted without any other    link level  mechanisms,     such
  4544.      as     connections  or  ack- nowledgements.
  4545.  
  4546.      In    "vc" (virtual circuit) mode, IP    packets    are encapsulated in  AX.25  I
  4547.      frames  and   are    acknowledged at    the link level according to the    AX.25
  4548.  
  4549.  
  4550.  
  4551.  
  4552.  
  4553.  
  4554.  
  4555.  
  4556.  
  4557.                       -    70 -
  4558.  
  4559.  
  4560.      protocol.    Link level connections are opened  if  necessary.   With  the
  4561.      proper   setting    of   the  AX.25     T2  (acknowledgement  delay)  timer,
  4562.      AX.25 acknowledgements can    be pig-    gybacked on I frames  carrying    other
  4563.      IP    datagrams (e.g., TCP level acknowledge-    ments),     thereby  eliminating
  4564.      the  extra    overhead ordinarily incurred by    link level acknowledgments.
  4565.  
  4566.      In    both modes, ARP    is used    to map IP to AX.25 addresses.    The  defaults
  4567.      can   be  overridden   with   the     type-of-service (TOS) bits in the IP
  4568.      header. Turning on    the "reliability" bit causes I    frames    to  be    used,
  4569.      while  turning   on  the  "low delay"  bit     uses UI frames.  (The effect
  4570.      of    turning    on both    bits is    undefined and subject to change).
  4571.  
  4572.      In    both modes, IP-level fragmentation is done if the datagram is  larger
  4573.      than the  interface  MTU.    In virtual circuit mode, however, the result-
  4574.      ing datagram (or fragments) is further fragmented at the AX.25 layer  if
  4575.      it      (or    they)  are still  larger  than    the  AX.25  "paclen"  parame-
  4576.      ter.  In AX.25 fragmentation, datagrams are broken    into several I frames
  4577.      and  reassembled  at  the    receiving end before being passed to IP. This
  4578.      is    preferable to IP fragmentation whenever    possible because of decreased
  4579.      overhead (the IP header isn't repeated  in     each fragment)    and increased
  4580.      robustness    (a lost    fragment is immediately    retransmit- ted    by  the     link
  4581.      layer).
  4582.  
  4583.      7.3.24.  mulport [on|off]
  4584.  
  4585.      The  multiport  switch software  allows routing of    frames between inter-
  4586.      faces based on a table lookup. This provides the traditional "multi-port
  4587.      digipeater" functionality.
  4588.  
  4589.      There are two tables that    you  must build    and place in the root  direc-
  4590.      tory.  They  are named  DIGILIST and EXLIST. DIGILIST contains the    digis
  4591.      that  are directly     reachable from    your switch. The  file    is  a  simple
  4592.      ASCII  text  file containing the callsign of the digi and the  interface
  4593.      name  of the port needed to reach it. The port name is  the   same     name
  4594.      you used in the attach statement for that port. Additionally there     is a
  4595.      special callsign "lan" that tells mulport which  port feeds your LAN  or
  4596.      default port.
  4597.  
  4598.      The file would look something like    this:
  4599.  
  4600.      kd4nc-1 ax1      #    kd4nc-1    is a neighbor switch on    the high speed
  4601.               #    link attached to ax1 wb4gqx-1 ax3     #    wb4gqx-1 is a
  4602.      neighbor  digi  on    145.01 (ax3) k4hal-1 ax2      #    k4hal-1    is a neighbor
  4603.      digi on 440 (ax2) lan  ax0        # lan is a special name    for  the  low
  4604.      speed  lan
  4605.               #    attached to the    switch and is the default port
  4606.               #    used when mycall is the    last call in the  digi
  4607.               #    string.
  4608.  
  4609.      The file EXLIST holds DESTINATION callsigns that do not obey  the rules.
  4610.      EXLIST  is    only for stations who would normally be    expected to be on the
  4611.      lan side  but are operating off some other    port instead.  A  couple   of
  4612.      reasons   that  this may be the case are that the station may be  a PBBS
  4613.      operating on the trunk to serve more than one lan.
  4614.  
  4615.  
  4616.  
  4617.  
  4618.  
  4619.  
  4620.  
  4621.  
  4622.  
  4623.                       -    71 -
  4624.  
  4625.  
  4626.      7.3.25.  param <interface>    [param]
  4627.  
  4628.      Param invokes a device-specific  control  routine.      On   a   KISS      TNC
  4629.      interface,     this    sends    control     packets  to the TNC.  Data bytes are
  4630.      treated as    decimal.  For example, "param ax0 1 255" will set  the    keyup
  4631.      timer  (type field     =  1)    on the    KISS  TNC  configured  as ax0 to 2.55
  4632.      seconds (255 x .01    sec).  On a SLIP interface, the    param command  allows
  4633.      the  baud    rate to    be  read  (without arguments) or set. The implementa-
  4634.      tion of this command for the various interface drivers is incomplete and
  4635.      subject to    change.
  4636.  
  4637.      7.3.26.  pwd [<dirname>]
  4638.  
  4639.      An    alias for the cd command.
  4640.  
  4641.      7.3.27.  record [<filename>|off]
  4642.  
  4643.      Opens <filename> and appends to it    all data  received  on    the   current
  4644.      session.  Data sent on the    current    session    is also    written    into the file
  4645.      except for    Tel- net sessions in remote echo mode.    The  command  "record
  4646.      off"   stops   recording  and  closes the file. This command is not sup-
  4647.      ported for    FTP sessions.
  4648.  
  4649.      7.3.28.  reset [<session>]
  4650.  
  4651.      If    an argument is given, force a local reset  (deletion)  of  the    AX.25
  4652.      (AXCB) or TCP  Control  Block  (TCB) belonging to the specified session.
  4653.      The argument is first checked for validity.  If no     argument  is  given,
  4654.      the current session,  if any,  is    used.    This  command  should be used
  4655.      with caution since    it does    not inform the remote end that the connection
  4656.      no     longer     exists.   (In TCP  a  reset (RST)  message will be automati-
  4657.      cally generated should the    remote TCP send     any-  thing  after  a    local
  4658.      reset  has     been  done.   In  AX.25  the DM message  performs  a similar
  4659.      role.   Both  are used to get rid of a  lingering    half-open  connection
  4660.      after a remote system has crashed.)
  4661.  
  4662.      7.3.29.  route
  4663.  
  4664.      route add <dest  hostid>[/bits]|default  <interface>  [<gateway  hostid>
  4665.          [<metric>]]
  4666.  
  4667.      route drop    <dest hostid>
  4668.  
  4669.      With no arguments,    "route"    displays the IP    routing     table.     "route     add"
  4670.      adds   an entry  to  the  routing    table,    while "route drop" deletes an
  4671.      existing entry.  "route add" requires at least two    more  arguments,  the
  4672.      host id  of  the  target destination and the local    name of    the interface
  4673.      to    which its packets should be sent.  If the destination is  not  local,
  4674.      the gateway's host    id should  also     be specified.    (If  the interface is
  4675.      a point-to-point link, then <gateway hostid> may be omitted even if  the
  4676.      target  is     non-local  because this field is only used to    determine the
  4677.      gateway's link level address, if any.  If the  destination     is  directly
  4678.      reachable,     <gateway  hostid>  is also unnecessary    since the destination
  4679.      address is    used to    determine the interface    link address).
  4680.  
  4681.  
  4682.  
  4683.  
  4684.  
  4685.  
  4686.  
  4687.  
  4688.  
  4689.                       -    72 -
  4690.  
  4691.  
  4692.      The optional "/bits" suffix to the    destination  host  id  specifies  how
  4693.      many  leading  bits  in  the host id are to be considered significant in
  4694.      the routing comparisons.  If not specified, 32 bits (i.e.,    full signifi-
  4695.      cance)  is     assumed.  With     this  option,    a  single routing table    entry
  4696.      may refer to many hosts all sharing a common bit string prefix in    their
  4697.      IP     addresses.  For  example,  ARPA Class    A, B and C networks would use
  4698.      suffixes of /8, /16 and /24 respectively; the command
  4699.  
  4700.          route add [44]/8 sl0 [44.64.0.2]
  4701.  
  4702.      causes any    IP addresses beginning with "44" in the    first 8    bits  to   be
  4703.      routed to [44.64.0.2]; the    remaining 24 bits are "don't-cares".
  4704.  
  4705.      When an IP    address    to be routed matches more than one   entry   in      the
  4706.      routing  table,   the   entry  with  largest "bits" parameter (i.e., the
  4707.      "best" match) is used. This allows    individual hosts or blocks  of    hosts
  4708.      to    be  exceptions    to  a more general rule    for a larger block of hosts.
  4709.  
  4710.      The  special  destination    "default"  is  used  to     route    datagrams  to
  4711.      addresses     not in     the  routing table; it    is equivalent to specifying a
  4712.      /bits suffix of /0    to any destination hostid.  Care must be  taken     with
  4713.      default   entries     since     two nodes  with  default entries pointing at
  4714.      each other    will route packets to unk- nown    addresses back and forth in a
  4715.      loop  until  their     time-to-live (TTL)  fields expire.   (Routing    loops
  4716.      for specific addresses can    also be    created, but this is less  likely  to
  4717.      occur accidentally).
  4718.  
  4719.      "route drop" deletes an entry from    the table.  If     a   packet   arrives
  4720.      for   the    deleted     address and a default route is    in effect, it will be
  4721.      used.
  4722.  
  4723.      Here are some examples of using the route command:
  4724.  
  4725.          # Route datagrams to IP address 44.0.0.3 to SLIP line #0.
  4726.          # No gateway is needed because SLIP is point-to point.
  4727.          route add [44.0.0.3] sl0
  4728.  
  4729.          # Route all default traffic to the    gateway    on the local Ethernet
  4730.          # with IP address [44.0.0.1]
  4731.          route add default ec0 [44.0.0.1]
  4732.  
  4733.          # The local Ethernet has an ARPA Class-C address assignment;
  4734.          # route all IP addresses beginning    with 192.4.8 to    it
  4735.          route add [192.4.8]/24 ec0
  4736.  
  4737.          # Station with IP address [44.0.0.10] on local AX.25 channel
  4738.          route add [44.0.0.10] ax0
  4739.  
  4740.      7.3.30.  session [<session    #>]
  4741.  
  4742.      Without arguments,    displays the list of  current    sessions,   including
  4743.      session number,  remote  TCP or AX.25 address and the address of the TCP
  4744.      or    AX.25 control block. An    asterisk (*) is    shown next to  the  "current"
  4745.      session;    entering  <cr>     at  this point    will put you in    converse mode
  4746.  
  4747.  
  4748.  
  4749.  
  4750.  
  4751.  
  4752.  
  4753.  
  4754.  
  4755.                       -    73 -
  4756.  
  4757.  
  4758.      with that session.     Entering a session number as an argument to the ses-
  4759.      sion  command  will  put  you  in converse     mode  with  that session. If
  4760.      the telnet    server is enabled, the user  is     notified  of    an   incoming
  4761.      request  and  a  session  number  is  automatically assigned.   The user
  4762.      may then select the session normally to converse with the remote user as
  4763.      though the    session    had been locally initiated.
  4764.  
  4765.      7.3.31.  shell
  4766.  
  4767.      Suspends "net" and    executes a sub    shell  ("command   processor"    under
  4768.      MS-DOS).  When  the  sub  shell  exits, net resumes (under    MS-DOS,    enter
  4769.      the "exit"    command). Note that background activity    (FTP  servers,     etc)
  4770.      is     also  suspended while the subshell executes.
  4771.  
  4772.      7.3.32.  smtp
  4773.  
  4774.      7.3.32.1.    smtp gateway [<hostid>]
  4775.  
  4776.      Displays or sets the host to be used as a "smart" mail relay.  Any     mail
  4777.      sent  to  a   hostid  not    in the host table will instead be sent to the
  4778.      gateway for forwarding.
  4779.  
  4780.      7.3.32.2.    smtp kick
  4781.  
  4782.      Run through the outgoing mail queue and attempt to    deliver    any   pending
  4783.      mail.   This  command is periodically invoked by a    timer whenever net is
  4784.      running; this command allows the user to "kick" the  mail    system    manu-
  4785.      ally.
  4786.  
  4787.      7.3.32.3.    smtp maxclients    [<val>]
  4788.  
  4789.      Displays or sets the maximum number  of   simultaneous   outgoing     SMTP
  4790.      sessions  that  will be allowed. The default is 10; reduce    it if network
  4791.      congestion    is a problem.
  4792.  
  4793.      7.3.32.4.    smtp timer [<val>]
  4794.  
  4795.      Displays or sets the interval, in seconds,    between    scans of the outbound
  4796.      mail queue. For example, "smtp timer 600" will cause the system to    check
  4797.      for outgoing mail every 10    minutes    and attempt to    deliver     anything  it
  4798.      finds,  subject  of course    to the "maxclients" limit. Setting a value of
  4799.      zero disables queue scanning altogether, note that    this is    the  default!
  4800.      This  value is recommended    for stand  alone  IP gateways that never han-
  4801.      dle mail, since it    saves wear and tear on the floppy disk drive.
  4802.  
  4803.      7.3.32.5.    smtp trace [<val>]
  4804.  
  4805.      Displays or sets the trace    flag in    the SMTP  client,  allowing  you   to
  4806.      watch  SMTP's   conversations   as    it delivers mail.  Zero    (the default)
  4807.      disables trac- ing.
  4808.  
  4809.      7.3.33.  start
  4810.  
  4811.      Starts  the  specified  Internet  server,    allowing  remote   connection
  4812.  
  4813.  
  4814.  
  4815.  
  4816.  
  4817.  
  4818.  
  4819.  
  4820.  
  4821.                       -    74 -
  4822.  
  4823.  
  4824.      requests.
  4825.  
  4826.      7.3.34.  stop
  4827.  
  4828.      Stops the specified Internet server,  rejecting   any   further   remote
  4829.      connect requests. Existing    connections are    allow to complete normally.
  4830.  
  4831.      7.3.35.  tcp
  4832.  
  4833.      7.3.35.1.    tcp irtt [<val>]
  4834.  
  4835.      Display or    set the    intial round trip time estimate, in  seconds,  to  be
  4836.      used  for    new  TCP  connections until they can measure and adapt to the
  4837.      actual value.  The    default    is 5 seconds.  Increasing this when operating
  4838.      over  slow    channels  will avoid the flurry    of retransmissions that    would
  4839.      otherwise occur as    the smoothed estimate settles  down  at     the  correct
  4840.      value.  Note  that     this command  should  be given     before     servers  are
  4841.      started in    order for it to    have effect on incoming    connections.
  4842.  
  4843.      7.3.35.2.    tcp kick <tcp_addr>
  4844.  
  4845.      If    there is data on the send queue    of the specified tcb,  this   command
  4846.      forces an immediate retransmission.
  4847.  
  4848.      7.3.35.3.    tcp mss    [<size>]
  4849.  
  4850.      Display or    set the    TCP Maximum Segment Size in bytes that will  be     sent
  4851.      on      all outgoing    TCP  connect  request (SYN segments).  This tells the
  4852.      remote end    the size of the    largest    segment    (packet) it may    send.  Chang-
  4853.      ing   MSS     affects   only     future    connections; existing connections are
  4854.      unaffected.
  4855.  
  4856.      7.3.35.4.    tcp reset <tcb_addr>
  4857.  
  4858.      Deletes the TCP control block at the specified address.
  4859.  
  4860.      7.3.35.5.    tcp rtt    <tcp_addr> <rtval>
  4861.  
  4862.      Replaces the automatically    computed round trip time in the    specified tcb
  4863.      with  the     rttval     in milliseconds.  This    command    is useful to speed up
  4864.      recovery from a series of lost packets since it provides a    manual bypass
  4865.      around  the  normal backoff retransmission    timing mechanisms.
  4866.  
  4867.      7.3.35.6.    tcp status [<tcb_addr>]
  4868.  
  4869.      Without arguments,    displays several TCP-level statistics, plus  a     sum-
  4870.      mary   of    all   existing    TCP  connections, including TCB    address, send
  4871.      and receive queue sizes, local and    remote sockets,    and connection state.
  4872.      If     <tcb_addr>  is    specified, a  more detailed dump of the    specified TCB
  4873.      is    generated, including send and  receive    sequence  numbers  and    timer
  4874.      information.
  4875.  
  4876.  
  4877.  
  4878.  
  4879.  
  4880.  
  4881.  
  4882.  
  4883.  
  4884.  
  4885.  
  4886.  
  4887.                       -    75 -
  4888.  
  4889.  
  4890.      7.3.35.7.    tcp window [<val>]
  4891.  
  4892.      Displays or sets the default receive window size in bytes    to  be     used
  4893.      by      TCP  when  creating new connections. Existing    connections are    unaf-
  4894.      fected.
  4895.  
  4896.      7.3.36.  telnet <hostid>
  4897.  
  4898.      Creates a Telnet session to the specified host and    enters converse    mode.
  4899.  
  4900.      7.3.37.  trace [<interface> [<flags>]|allmode|cmdmode]
  4901.  
  4902.      Controls packet tracing by    the interface drivers. Specific     bits  enable
  4903.      tracing  of   the    various    interfaces and the amount of information pro-
  4904.      duced.  Tracing is    controlled on a    per-interface  basis;  without    argu-
  4905.      ments, trace gives    a list    of all    defined     interfaces and    their tracing
  4906.      status.  Output can be limited to a single    interface by  specifying  it,
  4907.      and  the  control     flags    can  be     change     by specifying    them as    well.
  4908.      The flags are given as a hexadecimal number which is interpreted as fol-
  4909.      lows:
  4910.  
  4911.     TIO
  4912.     |||--- Enable tracing of output    packets    if 1, disable if 0
  4913.     ||---- Enable tracing of input packets if 1, disable if    0
  4914.     |----- Controls    type of    tracing:
  4915.        0 - Protocol    headers    are decoded, but data is not displayed
  4916.        1 - Protocol    headers    are decoded, and data (but not the
  4917.            headers themselves) are displayed as ASCII characters,
  4918.            64 characters/line. Unprintable characters are displayed
  4919.            as periods.
  4920.        2 - Protocol    headers    are decoded, and the entire packet
  4921.            (headers    AND data) is also displayed in hexadecimal
  4922.            and ASCII, 16 characters    per line.
  4923.  
  4924.      There is an additional option for tracing,    that  allows  you  to  select
  4925.      whether  traced packets are always    displayed, or only displayed when you
  4926.      are in command mode.  Having tracing only happen in command  mode    some-
  4927.      times  provides  the  right  mix  between "knowing    what's going on", and
  4928.      "keeping the garbage off the screen"  while  you're  typing.  To  select
  4929.      tracing  all  the time (the default mode),    use 'trace allmode'.  To res-
  4930.      trict tracing to command mode, use    'trace cmdmode'.
  4931.  
  4932.      7.3.38.  udp status
  4933.  
  4934.      Displays the status of all    UDP receive queues.
  4935.  
  4936.      7.3.39.  upload [<filename>]
  4937.  
  4938.      Opens <filename> and sends    it on the current session as though it     were
  4939.      typed on the terminal. Valid only on AX.25    and Telnet sessions.
  4940.  
  4941.      7.3.40.  ?
  4942.  
  4943.      Same as the "help"    command.
  4944.  
  4945.  
  4946.  
  4947.  
  4948.  
  4949.  
  4950.  
  4951.  
  4952.  
  4953.                       -    76 -
  4954.  
  4955.  
  4956.      8.     Appendices
  4957.  
  4958.      8.1.  Obtaining Current Bits
  4959.  
  4960.      The KA9Q Internet software    package    is still evolving and growing.    As  a
  4961.      result,  we  occasionally    issue  updates    to the software    that fix bugs
  4962.      and/or update functionality. Announcements    are always made    to the USENET
  4963.      news  group  rec.ham-radio.packet.      They    usually     also show up on Com-
  4964.      puserve within a day or two. There    is never any charge for    the software.
  4965.      A    small  charge  may exist for copying floppies if you want the bits on
  4966.      disk, and of course you'll    have to    pay the    long distance if you grab the
  4967.      bits over the phone!
  4968.  
  4969.      If    several    people are running the software    in your     area,    get  together
  4970.      and  decide  on one person    to get the new bits, then copy it around.  We
  4971.      won't mind.
  4972.  
  4973.      8.1.1.  Via FTP on    the Internet
  4974.  
  4975.      The most recent official release is usually available from     the  machine
  4976.      WSMR-SIMTEL20.ARMY.MIL  on     the Internet. Use anonymous FTP, and look in
  4977.      the directory PD3:<MISC.KA9Q-TCPIP>.
  4978.  
  4979.      Beta-releases are often available on the machine LOUIE.UDEL.EDU, in  the
  4980.      directory    tree  rooted  at  pub/ka9q.  Anonymous FTP's are allowed, but
  4981.      unless you're working  on    the  software,    the  bits  on  louie  can  be
  4982.      "dangerous",  as  they  often include incompletely    implemented features,
  4983.      and can have serious bugs.     Caveat    Emptor.
  4984.  
  4985.      Various bits are also available  from  TOMCAT.GSFC.NASA.GOV,  a  machine
  4986.      operated by Tom Clark W3IWI.
  4987.  
  4988.      8.1.2.  On    PC Floppies
  4989.  
  4990.      The Tucson    Amateur    Packet Radio association (TAPR)    now  provides  floppy
  4991.      copies  of     the  software on 360k PC floppies, and    can provide KISS ROMs
  4992.      for various TNC's,    at a nominal charge  for  duplication  and  shipping.
  4993.      Contact TAPR for more information.
  4994.  
  4995.       TAPR PO Box 12925 Tucson, AZ    85732 (602) 323-1710
  4996.  
  4997.      8.1.2.1.  WB3FFV's    Phone BBS in the USA
  4998.  
  4999.      Howard Leadmon, WB3FFV, has placed    a BBS system on-line that  is  mainly
  5000.      oriented  towards    the  Amateur  Community    (but there is other stuff on-
  5001.      line). Below is the information that is needed in order  to  access  the
  5002.      BBS via Telephone -or- TCP/IP.
  5003.  
  5004.       System Name: WB3FFV
  5005.       Login: bbs
  5006.       Number: (301)-335-0858 --    1200 & 2400 (Non-MNP)
  5007.       Number: (301)-335-1955 --    2400 (MNP), 9600 & 19200 (PEP)
  5008.       Data Settings: 8 Bits, NO    Parity,    1 Stop Bit
  5009.       Times: 24hrs/365days  (except for    routine    maintenance)
  5010.  
  5011.  
  5012.  
  5013.  
  5014.  
  5015.  
  5016.  
  5017.  
  5018.  
  5019.                       -    77 -
  5020.  
  5021.  
  5022.       Software:    XBBS  (UNIX/Xenix Multiuser BBS)
  5023.       IP Address: 44.60.0.1 {wb3ffv.ampr.org}  [for FTP    access on 145.550 mhz
  5024.      ONLY]
  5025.       Misc. Info: Machine  is  an  80386  computer  running  UNIX  V.3.2  and
  5026.      features 300+
  5027.           meg of on-line storage. Most transfer    protocols are  avail-
  5028.      able!!
  5029.  
  5030.      Howard attempts to    keep the latest    and greatest  HAM  software  on-line,
  5031.      and encourages all    to upload anything new that they come up with.
  5032.  
  5033.      8.1.2.2.  PA0GRI's    Phone BBS in Holland
  5034.  
  5035.      For those outside the USA,    particularly in    Europe,    Gerard    provides  BBS
  5036.      service  and  anonymous UUCP access to the    machine    'gvdgpc'. He supports
  5037.      Xmodem and    Kermit on the BBS, at 1200/2400    baud, auto baud     rate  detect
  5038.      by     hitting a carriage return, using 8 bits, NO Parity, 1 Stop Bit.  The
  5039.      telephone number is 0031-70-119549.
  5040.  
  5041.      For uucp, use login 'nuucp', with no password (you    won't be prompted for
  5042.      one).   Request the file ~/FILES to get started.  Gerard does a good job
  5043.      of    staying    up to date via a link to the wb3ffv machine.
  5044.  
  5045.      8.1.3.  Gary Sanders' Phone BBS in    the USA
  5046.  
  5047.      Gary Sanders, N8EMR, runs a system    called HBBS (Ham Bulletin board     sys-
  5048.      tem).   The  telephone number is  614-457-4227 (457-HBBS).    The system is
  5049.      online 24hrs a day    and will accept    1200/2400 and 19.2k baud PEP, 8     bits
  5050.      no    parity,    1 stop bit.
  5051.  
  5052.      Gary's system will    be used    to support topics of interest  to  Ham    Radio
  5053.      Operators,     Short    Wave  Listeners,  scanner  listeners, and TVRO users.
  5054.      Currently there are message and file upload/dowload sections for general
  5055.      ham radio,    packet radio, the KA9Q tcp software, SWL, and scanners.
  5056.  
  5057.      There is also readonly access to Unix USENET and  to  the    FIDO  network
  5058.      radio related newsgroups.
  5059.  
  5060.      Access to the BBS files are available via FTP  from  n8emr     [44.70.0.1].
  5061.      The  system  is available via 144.97 in Central Ohio, or via the 220 and
  5062.      446 packet    network    within Ohio.
  5063.  
  5064.      8.1.4.  Michael Broqvist in Sweden
  5065.  
  5066.      Michael operates a    BBS for    the Gothenburg Amateur Club called the HamNet
  5067.      Conference     System.   It  operates     at  +46/31-30    35 25, 300-2400    baud.
  5068.      Michael  can  be  reached    as  sysop  of  Fidonet    node  2:202/301,   as
  5069.      mibro@hamnet.se on    the Internet, or via uucp as enea!hamnet.se!mibro.
  5070.  
  5071.      He    also updates the packet    mailbox    SK6SA in Gothenburg Sweden  which  is
  5072.      reachable as 44.140.18.2.
  5073.  
  5074.  
  5075.  
  5076.  
  5077.  
  5078.  
  5079.  
  5080.  
  5081.  
  5082.  
  5083.  
  5084.  
  5085.                       -    78 -
  5086.  
  5087.  
  5088.      8.2.  The KISS Specification
  5089.  
  5090.      8.3.  The KISS Host to TNC    Protocol
  5091.  
  5092.      8.3.1.  The Protocol Specification
  5093.  
  5094.      8.3.1.1.  Introduction
  5095.  
  5096.      The purpose of the    "Raw" (aka "KISS") TNC is to facilitate     the  use  of
  5097.      amateur  packet  radio  controllers  (TNCs)  with    host  computers, par-
  5098.      ticularly in the development of experimental  protocols  and  multi-user
  5099.      servers (e.g.,  "bulletin boards").
  5100.  
  5101.      Current TNC software was  written    with  human  users  in    mind;  unfor-
  5102.      tunately,    commands   and    responses  well    suited for human use are ill-
  5103.      adapted for host computer use, and    vice versa. This is  especially     true
  5104.      for  multi-user  servers  such  as     bulletin boards which must multiplex
  5105.      data from several network connections across the single  host/TNC    link.
  5106.      In     addition,  experimentation  with   new      link    level    protocols  is
  5107.      greatly hampered because there may    very well be no    way at    all  to     gen-
  5108.      erate or receive frames in    the desired format without  reprogramming the
  5109.      TNC.
  5110.  
  5111.      The Raw TNC solves    these problems by eliminating  as  much     as  possible
  5112.      from   the     TNC software, giving the attached host    complete control over
  5113.      and access    to the contents    of the HDLC frames transmitted    and  received
  5114.      over  the air.  The  AX.25    protocol is removed entirely from the TNC, as
  5115.      are all command interpreters and the  like.   The    TNC  simply  converts
  5116.      between  synchronous  HDLC,  spoken  on  the half    duplex radio channel,
  5117.      and a special asynchronous, full  duplex  frame  format  spoken  on  the
  5118.      host/TNC  link.  Every  frame  received  on   the    HDLC  link  is passed
  5119.      intact to the host    once it    has been translated to the asynchronous     for-
  5120.      mat;  likewise, asynchronous frames from the host are transmitted on the
  5121.      radio channel once    they have been converted to HDLC format.
  5122.  
  5123.      Of    course,    this means that    the bulk of AX.25 (or another protocol)     must
  5124.      now  be  implemented   on    the host system. This is acceptable, however,
  5125.      considering the greatly increased flexibility and reduced    overall     com-
  5126.      plexity  that  comes  from    allowing  the  protocol    to reside on the same
  5127.      machine with the applications to which it is closely coupled.
  5128.  
  5129.      8.3.1.2.  Asynchtronous Frame Format
  5130.  
  5131.      The "asynchronous packet protocol"    spoken between the host     and  TNC  is
  5132.      very  simple,   since its only function is    delimiting frames. Each    frame
  5133.      is    both preceded and followed by a    special    FEND (frame  end)  character,
  5134.      analogous    to  an HDLC flag.  No CRC or checksum is provided.
  5135.  
  5136.      The reason    for both preceding and ending frames with FENDs    is to improve
  5137.      performance   when     there    is  noise on the asynch    line. The FEND at the
  5138.      beginning of a frame serves to "flush out"    any accumulated    garbage     into
  5139.      a    separate  frame    (which will be discarded by the    upper layer protocol)
  5140.      instead of    prepending it to an otherwise good frame.  As  with  back-to-
  5141.      back   FLAGs   in     HDLC,     two   FEND characters in a row    should not be
  5142.  
  5143.  
  5144.  
  5145.  
  5146.  
  5147.  
  5148.  
  5149.  
  5150.  
  5151.                       -    79 -
  5152.  
  5153.  
  5154.      interpreted as delimiting an empty    frame.
  5155.  
  5156.      8.3.1.2.1.     Transparency
  5157.  
  5158.      Frames are    sent in    8-bit binary; if an FEND ever appears in  the    data,
  5159.      it      is  translated   into      the    two   byte sequence FESC TFEND (frame
  5160.      escape, transposed    frame end).  Likewise, if  the    FESC  character     ever
  5161.      appears  in  the  user  data,  it    is  replaced  with  the    two character
  5162.      sequence FESC TFESC (frame    escape,    transposed frame escape).
  5163.  
  5164.      As    characters arrive at the receiver, they    are appended to    a buffer con-
  5165.      taining  the  current  frame.  Receiving  a  FEND    marks  the end of the
  5166.      current frame.  Receipt of    a  FESC     puts  the  receiver  into   "escaped
  5167.      mode",   which   causes   the receiver to translate a following TFESC or
  5168.      TFEND back    to FESC    or  FEND,  respectively,  before  adding  it  to  the
  5169.      receive  buffer  and  leaving  escaped  mode.  (Receipt  of  any charac-
  5170.      ter other than TFESC or TFEND while in escaped  mode  is  an  error;  no
  5171.      action  is     taken    and  frame  assembly  continues.   A  TFEND  or     TESC
  5172.      received while not    in escaped mode    is treated as an ordinary data    char-
  5173.      acter.)
  5174.  
  5175.      This procedure may    seem somewhat complicated, but it is easy  to  imple-
  5176.      ment  and recovers     quickly from errors. In particular, the FEND charac-
  5177.      ter is never sent over the    channel    except    as  an    actual     end-of-frame
  5178.      indication.   This      ensures that    any  intact frame (properly delimited
  5179.      by    FEND characters) will always be    received properly regardless  of  the
  5180.      starting state of the receiver or corruption of the preceding frame.
  5181.  
  5182.      The special characters are:
  5183.  
  5184.          FEND    (frame end)             300 (octal)
  5185.          FESC    (frame escape)             333 (octal)
  5186.          TFEND   (transposed frame end)         334 (octal)
  5187.          TFESC   (transposed frame escape)         335 (octal)
  5188.  
  5189.      (ARPA Internet hackers will recognize this     protocol  as  identical   to
  5190.      SLIP,   a popular method for sending IP datagrams across ordinary dialup
  5191.      modems).
  5192.  
  5193.      8.3.1.3.  Control of the Raw TNC
  5194.  
  5195.      Each asynchronous data frame sent to the TNC is  converted      back     into
  5196.      "pure"  form   and     queued     for  transmission  as a separate HDLC frame.
  5197.      Although removing the human interface and the AX.25  protocol  from  the
  5198.      TNC   makes  most    existing TNC  commands unnecessary (i.e., they become
  5199.      host  functions),    the  TNC  is  still  responsible   for     keying      the
  5200.      transmitter's   PTT   line      and    deferring  to  other activity  on the
  5201.      radio channel. It is therefore necessary to allow the host    to control  a
  5202.      few  TNC  parameters,  namely   the  transmitter  keyup  delay  and  the
  5203.      transmitter persistence variables.
  5204.  
  5205.      It    is therefore necessary    to  distinguish     between  command  and     data
  5206.      frames   on the  host/TNC    link. This is done by defining the first byte
  5207.      of    each asynchronous frame    between    host and TNC as    a  "type"  indicator.
  5208.  
  5209.  
  5210.  
  5211.  
  5212.  
  5213.  
  5214.  
  5215.  
  5216.  
  5217.                       -    80 -
  5218.  
  5219.  
  5220.      The  following  types are defined in frames to the    TNC:
  5221.  
  5222.      Type    Function         Comments
  5223.  
  5224.      0         Data frame         Rest of frame is data destined for    HDLC channel
  5225.  
  5226.      1         TXDELAY         Second byte is TX keyup delay in 10 ms units
  5227.  
  5228.      2         P             Second byte is persistence    parameter, p:
  5229.                  0:    p = (0+1)/256, 255: p =    (255+1)/256 = 1.0]
  5230.  
  5231.      3         SLOTTIME         Second byte is slot interval in 10    ms units
  5232.  
  5233.      4         TXtail         Second byte is time to hold up the    TX after
  5234.                  the FCS has been sent (time allowed to send the
  5235.                  HDLC flag character; should be at    least  2  for
  5236.                  1200 bps operation).  In 10 ms units.
  5237.  
  5238.      The following types are defined in    frames to the host:
  5239.  
  5240.      Type    Function         Comments
  5241.  
  5242.      0         Data frame         Rest of frame is data from    the HDLC channel
  5243.  
  5244.      (No other types are defined; in particular, there is  no  provision  for
  5245.      ack- nowledging data or command frames sent to the    TNC.)
  5246.  
  5247.      8.3.1.4.  Persistence
  5248.  
  5249.      The P and SLOTTIME    parameters are used to implement  true     p-persistent
  5250.      CSMA.  This works as follows:
  5251.  
  5252.      Whenever the host has queued data for transmission, the TNC begins     mon-
  5253.      itoring the  carrier detect signal    from the modem.    It waits indefinitely
  5254.      for this sig- nal to go inactive. Once the    channel    is clear,   the      TNC
  5255.      generates     a  random number  between  0 and 255. If this number is less
  5256.      than or equal to P, the TNC asserts the transmitter PTT line, waits  .01
  5257.      *    TXDELAY     seconds,   and     transmits all    frames    in its queue. The TNC
  5258.      then releases PTT and goes    back to    the idle state.     If the    random number
  5259.      is     greater  than    P, the    TNC  delays  signal  has gone  active  in the
  5260.      meantime, the TNC again waits for it  to  clear  before  con-  tinuing).
  5261.      Note   that   P=255   means   always   transmit  as  soon    as  possible,
  5262.      regardless    of the random number.
  5263.  
  5264.      The result    is that    the  TNC  waits     for   an   exponentially-distributed
  5265.      random  interval  after  sensing  that the    channel    has gone clear before
  5266.      attempting    to transmit. The idea here is that with    proper tuning of  the
  5267.      parameters     P  and    SLOTTIME,  several  stations with traffic to send are
  5268.      much less likely to col- lide with    each other when     they  simultaneously
  5269.      see the channel go    clear.
  5270.  
  5271.      8.3.2.  The TNC-2 Implementation
  5272.  
  5273.      See the files included in the TNC-2 KISS Distribution.
  5274.  
  5275.  
  5276.  
  5277.  
  5278.  
  5279.  
  5280.  
  5281.  
  5282.  
  5283.                       -    81 -
  5284.  
  5285.  
  5286.      8.3.3.  The TNC-1 Implementation
  5287.  
  5288.      See the files included in the TNC-1 KISS Distribution.
  5289.  
  5290.      8.3.4.  The VADCG/ASHBY Implementation
  5291.  
  5292.      See the files included in the VADCG/ASHBY KISS Distribution.
  5293.  
  5294.      8.3.5.  The AEA Implemenation
  5295.  
  5296.      All PK-232    units with WEFAX, and PC-87 units of a similar    vintage,  are
  5297.      capable of    KISS operation.     See the installation instructions earlier in
  5298.      this document for more information.
  5299.  
  5300.      8.3.6.  The Kantronics Implemenation
  5301.  
  5302.      See your Kantronics TNC Documentation.
  5303.  
  5304.      8.4.  The FTP, Inc., Packet Driver    Specification
  5305.  
  5306.      The KA9Q TCP/IP package includes a    driver that allows use of any network
  5307.      interface    that  is  provided  with a "packet driver" that    is compatible
  5308.      with the "PC/TCP Version  1.08  Packet  Driver  Specification",  by  FTP
  5309.      Software,    Inc.   The great benefit of the    packet driver spec is that it
  5310.      allows a manufacturer of a    PC networking interface     (an  Ethernet    card,
  5311.      etc),  to    write one driver that can be loaded for    use with a variety of
  5312.      networking    applications, including    the KA9Q package.
  5313.  
  5314.      For the benefit of    potential packet driver    authors, a copy    of  the     spec
  5315.      is     included  here.  A prolific packet driver author is Russ Nelson, who
  5316.      may be reached as nelson@sun.soe.clarkson.edu on the Internet.  Many  of
  5317.      the  drivers in use with the KA9Q package have been written or are    being
  5318.      maintained    by Russ.
  5319.  
  5320.      This  section is derived from a public domain document  created  by  FTP
  5321.      Software,    Inc.   FTP  Software  is  gratefully  acknowledged  for     both
  5322.      developing    the spec, and allowing use of their specification here.
  5323.  
  5324.       FTP Software,    Inc.
  5325.       P.O. Box 150
  5326.       Kendall Sq. Branch
  5327.       Boston, MA  02142
  5328.       (617)    868-4878
  5329.  
  5330.      Support of     a hardware interface, or mention of  an  interface  manufac-
  5331.      turer,  by     the  Packet   Driver    specification    does  not necessarily
  5332.      indicate     that  the  manufacturer  endorses this    specification.
  5333.  
  5334.      8.4.1.  Introduction and Motivation
  5335.  
  5336.      This document describes  the  programming    interface  to  PC/TCP  packet
  5337.      drivers.  Packet  drivers    provide      a   simple,       common programming
  5338.      interface that allows multiple applications  to share a  network  inter-
  5339.      face at the data link level. The packet drivers   demultiplex   incoming
  5340.  
  5341.  
  5342.  
  5343.  
  5344.  
  5345.  
  5346.  
  5347.  
  5348.  
  5349.                       -    82 -
  5350.  
  5351.  
  5352.      packets      amongst   the    applications by    using the network media     type
  5353.      field.
  5354.  
  5355.      Different    versions  of  PC/TCP  exist for    different network media    (Eth-
  5356.      ernet,  802.5  ring,  serial  lines), but    through    the use    of the packet
  5357.      driver,  the actual brand or model    of the network interface can be     hid-
  5358.      den from the application.
  5359.  
  5360.      The packet    driver provides    calls  to    initiate  access  to a  specific
  5361.      packet  type, to end access to it,    to send    a packet, to  get  statistics
  5362.      on     the    network    interface and  to  get information about  the  inter-
  5363.      face.
  5364.  
  5365.      Protocol  implementations    that use the  packet  driver  can  completely
  5366.      coexist on    a PC and can make use of one another's services, whereas mul-
  5367.      tiple applications    which do not use the driver do not  coexist   on  one
  5368.      machine  properly.     Through  use  of the packet driver, a user could run
  5369.      TCP/IP, DECnet, and a proprietary    protocol   implementation    such
  5370.      as      Banyan's,  LifeNet's,     Novell's    or     3COM's     without  the  diffi-
  5371.      culties associated    with preempting    the network interface.
  5372.  
  5373.      Applications which    use the    packet driver can also    run  on     new  network
  5374.      hardware  of  the same class  without  being modified; only a new packet
  5375.      driver need be supplied.
  5376.  
  5377.      Two  levels  of  packet  drivers  are   described     in  this  specifica-
  5378.      tion.  The     first    is  the    basic  packet  driver, which provides minimal
  5379.      functionality  but       should  be  simple  to implement and      which     uses
  5380.      very  few host resources. The basic driver    provides operations to broad-
  5381.      cast and receive packets.    The second driver  is  the   extended  packet
  5382.      driver,  which  is    a superset of the basic    driver.    The  extended  driver
  5383.      supports less commonly used functions of the  network    interface     such
  5384.      as      multicast,  and also gathers statistics  on  use  of    the interface
  5385.      and makes these available to the application.
  5386.  
  5387.      Functions which are available in  only  the  extended packet driver  are
  5388.      noted  as    such  in  their    descriptions. All basic    packet    driver    func-
  5389.      tions  are     available  in    the  extended driver.
  5390.  
  5391.      8.4.2.  Identifying network interfaces
  5392.  
  5393.      Network interfaces     are  named  by     a   triplet   of  integers,  <class,
  5394.      type,  number>.  The  first  is the class of interface.  The class    tells
  5395.      what    kind  of  media  the interface is for: DEC/Intel/Xerox/Ethernet,
  5396.      IEEE    802.3    Ethernet,      IEEE 802.5/Token Ring, ProNET-10, Broadband
  5397.      Ethernet,    Appletalk, serial line,    etc.
  5398.  
  5399.      The second    number is the type of interface: this specifies    a  particular
  5400.      instance  of  an  interface   supporting    a  class of medium. Interface
  5401.      types  for     Ethernet  might   name      these     interfaces:  3COM  3C501  or
  5402.      3C505,  Interlan  NI5010,    Univation, BICC        Data   Networks   ISOLAN,
  5403.      Ungermann-Bass  NIC,  etc.     Interface types for IEEE  802.5  might     name
  5404.      these interfaces: IBM Token Ring adapter, Proteon p1340, etc.
  5405.  
  5406.  
  5407.  
  5408.  
  5409.  
  5410.  
  5411.  
  5412.  
  5413.  
  5414.  
  5415.                       -    83 -
  5416.  
  5417.  
  5418.      The last number is     the  interface     number. If  a    machine     is  equipped
  5419.      with  more    than one interface of a     class    and type, the interfaces must
  5420.      be    numbered to distinguish    between    them.
  5421.  
  5422.      An    appendix details constants  for     classes  and  types. The class    of an
  5423.      interface    is  an 8-bit integer, and its type is a    16 bit integer.    Class
  5424.      and  type constants are  managed  by  FTP    Software.  Contact   FTP   to
  5425.      register  a new class  or    type number.
  5426.  
  5427.      The  type    0xFFFF    is  a  wildcard     type  which matches   any  interface
  5428.      in       the    specified  class.   It    is  unnecessary    to wildcard interface
  5429.      numbers, as 0 will     always     correspond to the  first  interface  of  the
  5430.      specified class and type.
  5431.  
  5432.      This specification     has  no  provision  for  the    support     of  multiple
  5433.      network   interfaces   (with    similar   or  different characteristics)
  5434.      via a single Packet Driver    and   associated  interrupt.  We  feel     that
  5435.      this   issue  is best addressed by    loading     several  Packet Drivers, one
  5436.      per   interface,    with  different     interrupts   (although       all      may
  5437.      be       included   in  a  single   TSR   software   module).     Applications
  5438.      software must check the  class and    type returned  from  a    driver_info()
  5439.      call  already,   to  make    sure  that  the     Packet     Driver     is  for  the
  5440.      correct  media  and  packet  format.     This    can easily  be general-
  5441.      ized  by searching    for another    Packet  Driver  if the first is not of
  5442.      the right kind.
  5443.  
  5444.      8.4.3.  Initiating    driver operations
  5445.  
  5446.      The packet    driver is invoked via a    software interrupt in the range     0x60
  5447.      through  0x80.  This  document  does not specify a    particular interrupt,
  5448.      but   describes   a   mechanism    for    locating       which    interrupt
  5449.      the    driver  uses.  The     interrupt  must be configurable    to    avoid
  5450.      conflicts    with  other  pieces  of    software   that      also    use  software
  5451.      interrupts. The  program which  installs  the     packet  driver  should
  5452.      provide  some mechanism for the user to specify the interrupt.
  5453.  
  5454.      The handler for the  interrupt  is     assumed  to start with     3  bytes  of
  5455.      exectuable    code; this can either be    a  3-byte jump instruction,       or
  5456.      a 2-byte jump followed by    a  NOP    (do  not specify "jmp short"   unless
  5457.      you   also      specify   an explicit    NOP). This must    be  followed  by  the
  5458.      null-terminated ASCII text    string "PKT DRVR".  To     find  the  interrupt
  5459.      being  used  by  the  driver,  an    application  should scan through  the
  5460.      handlers for  vectors    0x60  through 0x80 until it finds    one with  the
  5461.      text string "PKT DRVR" in it.
  5462.  
  5463.      8.4.4.  Programming interface
  5464.  
  5465.      All  functions  are  accessed  via     the  software    interrupt  determined
  5466.      to     be  the  driver's   via  the  mechanism described earlier. On entry,
  5467.      register AH contains  the    code  of  the function desired.
  5468.  
  5469.      The handle    is an    arbitrary   integer    value   associated  with     each
  5470.      MAC-level     demultiplexing     type  that  has  been    established  via  the
  5471.      access_type  call.     Internally  to      the       packet  driver,  it     will
  5472.  
  5473.  
  5474.  
  5475.  
  5476.  
  5477.  
  5478.  
  5479.  
  5480.  
  5481.                       -    84 -
  5482.  
  5483.  
  5484.      probably    be   a    pointer,  or  a    table offset. The application calling
  5485.      the packet    driver    cannot    depend    on it assuming any particular  range,
  5486.      or    any other characteristics.
  5487.  
  5488.      Note that    some   of   the     functions  defined  below  are     labelled  as
  5489.      extended     driver     functions.  Because   these   are   not required for
  5490.      basic  network  operations,   their  implementation  may  be  considered
  5491.      optional.        Programs  wishing  to  use these functions should use the
  5492.      driver_info() function to determine if they are  available     in  a    given
  5493.      packet driver.
  5494.  
  5495.      8.4.4.1.  Entry Conditions
  5496.  
  5497.      FTP Software applications which call the  packet  driver  are  coded  in
  5498.      Microsoft    C  and assembly    language. All necessary    registers  are    saved
  5499.      by     FTP's     routines   before   the   INT    instruction  to      call      the
  5500.      packet  driver  is     executed. Our current receiver() functions behave as
  5501.      follows: DS  and the flags     are  saved  and restored. All    other  regis-
  5502.      ters may be modified,  and     should     be saved by the  packet  driver,  if
  5503.      necessary.     Processor  interrupts    may  be     enabled  while          in  the
  5504.      upcall,   but    the   upcall  doesn't  assume  interrupts     are disabled
  5505.      on    entry. On entry, receiver() switches to    a local     stack.     Current  FTP
  5506.      Software receiver() routines  may modify all registers except DS, so the
  5507.      caller must save and restore any that must    be preserved across the    call.
  5508.  
  5509.      Note    that  some     older    versions  of    PC/TCP      may  enable  inter-
  5510.      rupts  during  the      upcall,  and    leave  them  enabled on    return to the
  5511.      Packet Driver.
  5512.  
  5513.      8.4.4.2.  Byte ordering
  5514.  
  5515.      Developers    should note that, on many    networks  and protocol families,
  5516.      the   byte-ordering  of 16-bit  quantities     on  the network  is opposite
  5517.      to    the native  byte-order    of  the     PC.   (802.5    Token    Ring   is  an
  5518.      exception).  This means that DEC- Intel-Xerox ethertype values passed to
  5519.      access_type() must    be swapped (passed in network order).        The     IEEE
  5520.      802.3  length  field  needs   similar handling, and care should be    taken
  5521.      with packets  passed to send_pkt(),  so  they   are   in    the    proper
  5522.      order.
  5523.  
  5524.      8.4.4.3.  driver_info()
  5525.  
  5526.       driver_info(handle)        AH == 1 AL == FF
  5527.         int        handle; BX            /* Optional    */
  5528.  
  5529.       error    return:
  5530.        carry flag set
  5531.        error code            DH
  5532.        possible errors:
  5533.         BAD_HANDLE                /* older drivers only */
  5534.  
  5535.       non-error return:
  5536.        carry flag clear
  5537.        version            BX
  5538.  
  5539.  
  5540.  
  5541.  
  5542.  
  5543.  
  5544.  
  5545.  
  5546.  
  5547.                       -    85 -
  5548.  
  5549.  
  5550.        class           CH
  5551.        type                DX
  5552.        number        CL
  5553.        name                DS:SI
  5554.        basic/extended   AL
  5555.  
  5556.             1 == basic,    2 == extended, FF == not installed
  5557.  
  5558.      This function returns information about the interface. The     version   is
  5559.      assumed    to  be    an  internal  hardware    driver identifier. In earlier
  5560.      versions  of  this    spec, the handle  argument   (which  must  have     been
  5561.      obtained via    access_type()) was    required. It is      now  optional,  but
  5562.      drivers developed according  to versions  of  this     spec    previous   to
  5563.      1.07  may require it, so implementers should take care.
  5564.  
  5565.      8.4.4.4.  access_type()
  5566.  
  5567.       int  access_type(if_class,  if_type,    if_number,   type,   typelen,
  5568.       receiver) AH == 2
  5569.         int        if_class;            AL
  5570.         int        if_type;            BX
  5571.         int        if_number;            DL
  5572.         char far *type;            DS:SI
  5573.         unsigned typelen;            CX
  5574.         int        (far *receiver)();        ES:DI
  5575.  
  5576.       error    return:
  5577.        carry flag set
  5578.        error code                DH
  5579.        possible errors:
  5580.         NO_CLASS
  5581.         NO_TYPE
  5582.         NO_NUMBER
  5583.         BAD_TYPE
  5584.         NO_SPACE
  5585.         TYPE_INUSE
  5586.  
  5587.       non-error return:
  5588.        carry flag clear
  5589.        handle            AX
  5590.        receiver call:
  5591.        (*receiver)(handle, flag, len [, buffer])
  5592.         int        handle;        BX
  5593.         int        flag;        AX
  5594.         unsigned len;        CX
  5595.        if AX == 1,
  5596.         char far *buffer;        DS:SI
  5597.  
  5598.      Initiates access  to    packets  of  the  specified  type.    The  argument
  5599.      type  is    a   pointer  to     a  packet type    specification.    The  argument
  5600.      typelen is    the length in  bytes   of   the      type    field.    The  argument
  5601.      receiver    is   a     pointer  to  a     subroutine which is called when    a
  5602.      packet is received.   If the typelen argument is 0, this indicates     that
  5603.      the  caller  wants     to  match all packets (match all requests  may       be
  5604.  
  5605.  
  5606.  
  5607.  
  5608.  
  5609.  
  5610.  
  5611.  
  5612.  
  5613.                       -    86 -
  5614.  
  5615.  
  5616.      refused  by packet    drivers     developed  to     conform   to    versions   of
  5617.      this spec previous    to 1.07).
  5618.  
  5619.      When a packet is received,    receiver is called   twice    by  the  packet
  5620.      driver.  The  first  time    is to request a    buffer    from the  application
  5621.      to       copy    the packet into.  AX ==    0  on  this  call.  The      application
  5622.      should  return  a pointer to the buffer in    ES:DI. If the application has
  5623.      no    buffers,      it  may return 0:0  in  ES:DI,  and the  driver  should
  5624.      throw away    the packet and not perform the second call.
  5625.  
  5626.      It    is important that the packet length (CX) be valid    on    the AX    ==  0
  5627.      call,  so    that  the receiver can allocate    a  buffer of the proper    size.
  5628.      This length (as well as the copy performed    prior to the AX     ==  1    call)
  5629.      must  include  the      Ethernet  header and all received data, but not the
  5630.      trailing checksum.
  5631.  
  5632.      On    the second call, AX == 1. This call  indicates    that   the  copy  has
  5633.      been  completed,     and the application may do as it wishes  with      the
  5634.      buffer. The buffer    that  the  packet  was copied into is pointed  to  by
  5635.      DS:SI.
  5636.  
  5637.      8.4.4.5.  release_type()
  5638.  
  5639.       int release_type(handle)        AH == 3
  5640.         int        handle;        BX
  5641.  
  5642.       error    return:
  5643.        carry flag set
  5644.        error code                DH
  5645.        possible errors:
  5646.         BAD_HANDLE
  5647.  
  5648.       non-error return:
  5649.        carry flag clear
  5650.  
  5651.      This function  ends  access  to  packets    associated    with  a  handle
  5652.      returned by  access_type(). The handle is no longer valid.
  5653.  
  5654.      8.4.4.6.  send_pkt()
  5655.  
  5656.       int send_pkt(buffer, length)        AH == 4
  5657.         char far *buffer;        DS:SI
  5658.         unsigned length;        CX
  5659.  
  5660.       error    return:
  5661.        carry flag set
  5662.        error code                DH
  5663.        possible errors:
  5664.         CANT_SEND
  5665.  
  5666.       non-error return:
  5667.        carry flag clear
  5668.  
  5669.      Transmits length bytes  of     data,    starting  at  buffer. The application
  5670.  
  5671.  
  5672.  
  5673.  
  5674.  
  5675.  
  5676.  
  5677.  
  5678.  
  5679.                       -    87 -
  5680.  
  5681.  
  5682.      must  supply  the    entire packet, including  local    network     headers. Any
  5683.      MAC or LLC    information  in     use  for packet  demultiplexing  (e.g.      the
  5684.      DEC-Intel-Xerox  Ethertype)  must    be  filled in  by  the application as
  5685.      well. This    cannot be performed by the  driver, as no handle is specified
  5686.      in    a call to the send_packet() function.
  5687.  
  5688.      8.4.4.7.  terminate()
  5689.  
  5690.       terminate(handle)            AH == 5
  5691.         int        handle;        BX
  5692.  
  5693.       error    return:
  5694.        carry flag set
  5695.        error code                DH
  5696.        possible errors:
  5697.         BAD_HANDLE
  5698.         CANT_TERMINATE
  5699.  
  5700.       non-error return:
  5701.        carry flag clear
  5702.  
  5703.      Terminates     the driver associated with handle. If    possible, the  driver
  5704.      will exit and  allow MS-DOS to reclaim the    memory it was using.
  5705.  
  5706.      8.4.4.8.  get_address()
  5707.  
  5708.       get_address(handle, buf, len)      AH ==    6
  5709.         int        handle;        BX
  5710.         char far *buf;        ES:DI
  5711.         int        len;        CX
  5712.  
  5713.       error    return:
  5714.        carry flag set
  5715.        error code                DH
  5716.        possible errors:
  5717.         BAD_HANDLE
  5718.         NO_SPACE
  5719.  
  5720.       non-error return:
  5721.        carry flag clear
  5722.        length        CX
  5723.  
  5724.      Copies the    local net    address  associated  with    handle into buf.  The
  5725.      buffer  buf  is  len  bytes  long.    The actual  number of bytes copied is
  5726.      returned in CX. If    the  NO_SPACE  error   is  returned,  this  indicates
  5727.      that len was  insufficient     to hold the local net address.
  5728.  
  5729.      8.4.4.9.  reset_interface()
  5730.  
  5731.       reset_interface(handle)   AH == 7
  5732.         int        handle;        BX
  5733.  
  5734.       error    return:
  5735.        carry flag set
  5736.  
  5737.  
  5738.  
  5739.  
  5740.  
  5741.  
  5742.  
  5743.  
  5744.  
  5745.                       -    88 -
  5746.  
  5747.  
  5748.        error code                 DH
  5749.        possible errors:
  5750.         BAD_HANDLE
  5751.  
  5752.       non-error return:
  5753.        carry flag clear
  5754.  
  5755.      Resets the     interface  associated    with   handle    to   a    known  state,
  5756.      aborting any  transmits in    process    and reinitializing the receiver. This
  5757.      call  has    been  included    primarily for circumstances  where  a    high-
  5758.      level  protocol  has  detected  what  it  thinks  may  be    an  interface
  5759.      failure  or hang.       If the packet driver     implementer has a high    level
  5760.      of     confidence in the hardware, or    the action  would  seriously  disrupt
  5761.      other users of the    interface, this    can be treated as a no-op.
  5762.  
  5763.      8.4.4.10.    set_rcv_mode()
  5764.  
  5765.       extended driver function
  5766.        set_rcv_mode(handle,    mode)        AH == 20
  5767.         int        handle;        BX
  5768.         int        mode;        CX
  5769.  
  5770.       error    return:
  5771.        carry flag set
  5772.        error code            DH
  5773.        possible errors:
  5774.         BAD_HANDLE
  5775.         BAD_MODE
  5776.  
  5777.       non-error return:
  5778.        carry flag clear
  5779.  
  5780.      Sets the  receive    mode  on  the  interface  associated with handle. The
  5781.      following values are accepted for mode:
  5782.       mode          meaning
  5783.  
  5784.        1          turn off receiver
  5785.        2          receive only packets sent    to this    interface
  5786.        3          mode 2 plus broadcast packets
  5787.        4          mode 3 plus limited multicast packets
  5788.        5          mode 3 plus all multicast    packets
  5789.        6          all packets
  5790.  
  5791.      Note that    not all     interfaces  support  all  modes.  The    receive     mode
  5792.      affects  all  packets  received  by  this      interface, not just packets
  5793.      associated      with     the  handle  argument.     See  the  extended    driver
  5794.      functions        get_multicast_list()     and  set_multicast_list()      for
  5795.      programming  "perfect filters" to receive specific    multicast addresses.
  5796.  
  5797.      Note that mode 3 is the default, and    if     the set_rcv_mode()  function
  5798.      is     not  implemented, mode    3 is  assumed  to    be     in force as long  as
  5799.      any  handles  are      open    (from  the first access_type()    to  the     last
  5800.      release_type()).
  5801.  
  5802.  
  5803.  
  5804.  
  5805.  
  5806.  
  5807.  
  5808.  
  5809.  
  5810.  
  5811.                       -    89 -
  5812.  
  5813.  
  5814.      8.4.4.11.    get_rcv_mode()
  5815.  
  5816.       extended driver function get_rcv_mode(handle,    mode)         AH    == 21
  5817.         int        handle;        BX
  5818.  
  5819.       error    return:
  5820.        carry flag set
  5821.        error code                DH
  5822.        possible errors:
  5823.         BAD_HANDLE
  5824.  
  5825.       non-error return:
  5826.        carry flag clear
  5827.        mode                    AX
  5828.  
  5829.      Returns the current receive mode of the interface associated  with     han-
  5830.      dle.
  5831.  
  5832.      8.4.4.12.    set_multicast_list()
  5833.  
  5834.       extended driver function  set_multicast_list(addrlst,     len)
  5835.       AH ==    22
  5836.         char far *addrlst;        ES:DI
  5837.         int        len;        CX
  5838.  
  5839.       error    return:
  5840.        carry flag set
  5841.        error code                DH
  5842.        possible errors:
  5843.         NO_MULTICAST
  5844.         NO_SPACE
  5845.         BAD_ADDRESS
  5846.  
  5847.       non-error return:
  5848.        carry flag clear
  5849.  
  5850.      The  addrlst argument is assumed to   point   to    an   len-byte  buffer
  5851.      containing       a    number     of    multicast  addresses.  BAD_ADDRESS is
  5852.      returned if len modulo the    size of    an address is  not equal to 0, or the
  5853.      data   is    unacceptable  for  some    reason.    NO_SPACE is returned  (and no
  5854.      addresses    are  set)  if  there    are   more   addresses      than      the
  5855.      hardware    supports directly.
  5856.  
  5857.      The recommended procedure for setting multicast addresses is to issue  a
  5858.      get_multicast_list(),  copy  the    information  to    a local     buffer,  add
  5859.      any  addresses   desired,     and   issue   a  set_multicast_list().     This
  5860.      should   be    reversed    when    the   application   exits.   If      the
  5861.      set_multicast_list() fails    due to NO_SPACE, use  set_rcv_mode()  to  set
  5862.      mode 5 instead.
  5863.  
  5864.      8.4.4.13.    get_multicast_list()
  5865.  
  5866.       extended driver function get_multicast_list()             AH    == 23
  5867.  
  5868.  
  5869.  
  5870.  
  5871.  
  5872.  
  5873.  
  5874.  
  5875.  
  5876.  
  5877.                       -    90 -
  5878.  
  5879.  
  5880.       error    return:
  5881.        carry flag set
  5882.        error code                DH
  5883.        possible errors:
  5884.         NO_MULTICAST
  5885.  
  5886.       non-error return:
  5887.        carry flag clear
  5888.        char    far *addrlst;            ES:DI
  5889.        int        len;            CX
  5890.  
  5891.      On     a  successful    return,    addrlst    points to    len  bytes     of multicast
  5892.      addresses     currently  in    use. The  application program must not modify
  5893.      this information in-place.
  5894.  
  5895.      8.4.4.14.    get_statistics()
  5896.  
  5897.       extended driver function get_statistics(handle)    AH    == 24
  5898.         int    handle;            BX
  5899.  
  5900.       error    return:
  5901.        carry flag set
  5902.        error code                DH
  5903.        possible errors:
  5904.         BAD_HANDLE
  5905.  
  5906.       non-error return:
  5907.        carry flag clear
  5908.        char    far *stats;            DS:SI
  5909.  
  5910.       statistics structure:
  5911.        field           byte    length
  5912.        packets in            4
  5913.        packets out            4
  5914.        bytes in            4
  5915.        bytes out            4
  5916.        errors in            4
  5917.        errors out            4
  5918.        packets dropped        4
  5919.  
  5920.      Returns a pointer to a statistics structure for this handle.
  5921.  
  5922.      8.4.4.15.    set_address()
  5923.  
  5924.       extended driver function set_address(addr, len)    AH    == 25
  5925.         char far *addr;        ES:DI
  5926.         int    len;            CX
  5927.  
  5928.       error    return:
  5929.        carry flag set
  5930.        error code                DH
  5931.        possible errors:
  5932.         CANT_SET
  5933.         BAD_ADDRESS
  5934.  
  5935.  
  5936.  
  5937.  
  5938.  
  5939.  
  5940.  
  5941.  
  5942.  
  5943.                       -    91 -
  5944.  
  5945.  
  5946.       non-error return:
  5947.        carry flag clear
  5948.        length            CX
  5949.  
  5950.      This call is used when  the  application  or    protocol stack needs  to
  5951.      use  a specific LAN address.     For  instance, DECnet protocols on Eth-
  5952.      ernet encode    the  protocol  address  in    the Ethernet address, requir-
  5953.      ing  that    it  be    set when the protocol stack is loaded. A  BAD_ADDRESS
  5954.      error  indicates  that the    Packet Driver  doesn't    like  the   len     (too
  5955.      short  or    too  long), or the data     itself.     Note that packet drivers
  5956.      should refuse to change the address (with a CANT_SET  error)   if     more
  5957.      than  one    handle    is   open   (lest   it     be  changed  out  from    under
  5958.      another protocol stack).
  5959.  
  5960.      8.4.5.  Interface classes and types
  5961.  
  5962.      The following are defined    as  network  interface    classes,  with    their
  5963.      individual    types  listed  immediately    following     the class.
  5964.  
  5965.       DEC/Intel/Xerox "Bluebook" Ethernet         1
  5966.  
  5967.            3COM 3C500/3C501        1  3COM     3C505            2  MICOM-
  5968.            Interlan     NI5010      3  BICC Data Networks    4110 4 BICC Data Net-
  5969.            works  4117 5  MICOM-Interlan  NP600    6  Ungermann-Bass  PC-
  5970.            NIC   8    Univation  NC-516     9 TRW PC-2000           10
  5971.            MICOM-Interlan  NI5210    11  3COM  3C503             12     3COM
  5972.            3C523          13  Western  Digital WD8003  14 Spider Sys-
  5973.            tems S4         15    Torus Frame Level    16  10NET  Communica-
  5974.            tions    17    Gateway     PC-bus         18    Gateway      AT-
  5975.            bus        19        Gateway     MCA-bus     20      IMC
  5976.            PCnic           21  IMC  PCnic  II         22 IMC    PCnic
  5977.            8bit         23
  5978.  
  5979.       ProNET-10              2
  5980.  
  5981.             Proteon p1300           1
  5982.  
  5983.       IEEE 802.5/ProNET-4          3
  5984.  
  5985.             IBM    Token ring adapter     1
  5986.             Proteon p1340           2
  5987.             Proteon p1344           3
  5988.             Gateway PC-bus           4
  5989.             Gateway AT-bus           5
  5990.             Gateway MCA-bus           6
  5991.  
  5992.       Omninet              4
  5993.  
  5994.       Appletalk              5
  5995.  
  5996.       Serial line              6
  5997.  
  5998.       Starlan              7    (NOTE: subsumed by Ethernet)
  5999.  
  6000.  
  6001.  
  6002.  
  6003.  
  6004.  
  6005.  
  6006.  
  6007.  
  6008.  
  6009.                       -    92 -
  6010.  
  6011.  
  6012.       ArcNet              8
  6013.  
  6014.            Datapoint RIM           1
  6015.  
  6016.       AX.25                  9
  6017.  
  6018.       KISS                  10
  6019.  
  6020.       IEEE 802.3 w/802.2 hdrs      11
  6021.  
  6022.            Types as    given under DIX    Ethernet, See Appendix D.
  6023.  
  6024.      8.4.6.  Function call numbers
  6025.  
  6026.      The following numbers are used  to     specify  which    operation the  packet
  6027.      driver  should  perform. The  number is stored in register    AH on call to
  6028.      the packet    driver.
  6029.  
  6030.        driver_info              1
  6031.        access_type              2
  6032.        release_type              3
  6033.        send_pkt              4
  6034.        terminate              5
  6035.        get_address              6
  6036.        reset_interface          7
  6037.        *set_rcv_mode         20
  6038.        *get_rcv_mode         21
  6039.        *set_multicast_list          22
  6040.        *get_multicast_list          23
  6041.        *get_statistics          24
  6042.        *set_address              25
  6043.  
  6044.       * indicates an extended packet driver    function
  6045.  
  6046.      8.4.7.  Error codes
  6047.  
  6048.      Packet driver calls indicate error    by setting the carry flag on  return.
  6049.      The error code is returned     in  register         DH     (a register not used
  6050.      to    pass values to functions  must    be used    to return  the    error  code).
  6051.      The  following  error  codes are defined:
  6052.  
  6053.        1    BAD_HANDLE         invalid handle number
  6054.  
  6055.        2    NO_CLASS         no    interfaces of specified    class found
  6056.  
  6057.        3    NO_TYPE         no    interfaces of specified    type found
  6058.  
  6059.        4    NO_NUMBER         no    interfaces of specified    number found
  6060.  
  6061.        5    BAD_TYPE         bad packet    type specified
  6062.  
  6063.        6       NO_MULTICAST    this    interface    does     not     support
  6064.                  multicast
  6065.  
  6066.  
  6067.  
  6068.  
  6069.  
  6070.  
  6071.  
  6072.  
  6073.  
  6074.  
  6075.                       -    93 -
  6076.  
  6077.  
  6078.        7    CANT_TERMINATE   this packet driver    cannot terminate
  6079.  
  6080.        8    BAD_MODE         an    invalid    receiver mode was specified
  6081.  
  6082.        9     NO_SPACE           operation  failed  because   of     insufficient
  6083.                  space
  6084.  
  6085.        10    TYPE_INUSE          the  type      had    previously   been   accessed,
  6086.                  and not released.
  6087.  
  6088.        11    BAD_COMMAND      the  command  was     out   of   range,   or      not
  6089.                  implemented
  6090.  
  6091.        12     CANT_SEND           the   packet   couldn't     be   sent   (usually
  6092.                  hardware error)
  6093.  
  6094.        13     CANT_SET         hardware   address   couldn't     be   changed
  6095.                  (more than    1 handle open)
  6096.  
  6097.        14     BAD_ADDRESS      hardware      address   has      bad     length       or
  6098.                  format
  6099.  
  6100.      8.4.8.  802.3 vs. Blue Book Ethernet
  6101.  
  6102.      One weakness of  the    present specification is that there is no provi-
  6103.      sion  for    simultaneous  support  of  802.3  and Blue Book    (the old DEC-
  6104.      Intel-Xerox standard)  Ethernet    headers     via a single  Packet  Driver
  6105.      (as  defined   by      its  interrupt). The problem is that the  Ethertype
  6106.      of     Blue  Book packets is in bytes      12   and    13   of    the   header,
  6107.      and    in     802.3    the corresponding bytes     are interpreted as a length.
  6108.      In    802.3, the field which would appear to be most useful to   begin  the
  6109.      type    check   in     is  the  802.2     header,   starting   at   byte      14.
  6110.      This    is     only  a  problem  on Ethernet and   variants    (e.g.    Star-
  6111.      lan),  where 802.3     headers  and  Blue  Book  headers are likely to need
  6112.      co-exist for many years to    come.
  6113.  
  6114.      One solution is to    redefine  class     1  as     Blue     Book  Ethernet,  and
  6115.      define  a parallel    class for  802.3  with    802.2     packet    headers. This
  6116.      requires that  a  2nd  Packet  Driver  (as     defined  by  its  interrupt)
  6117.      be       implemented      where       it  is  necessary  to  handle  both    kinds
  6118.      of       packets,  although  they could  both     be  part  of  the  same  TSR
  6119.      module.
  6120.  
  6121.      As    of this    draft, class 11    has  been  assigned  to      802.3     using    802.2
  6122.      headers, to implement the above.
  6123.  
  6124.      Note: According to    this scheme,  an  application  wishing to receive  IP
  6125.      encapsulated   per      RFC  1042  would  specify an typelen argument    of 8,
  6126.      and type would point to:
  6127.       char        iee_ip[] = {0xAA, 0xAA, 3, 0, 0, 0,    0x08, 0x00};
  6128.  
  6129.      8.5.  Information for Software Developers
  6130.  
  6131.  
  6132.  
  6133.  
  6134.  
  6135.  
  6136.  
  6137.  
  6138.  
  6139.  
  6140.  
  6141.                       -    94 -
  6142.  
  6143.  
  6144.      8.6.  Technical Information for Client/Server Developers
  6145.  
  6146.      First things first.  The program has been tested out with    the  Turbo  C
  6147.      2.0  compiler under MS-Dos, the HP-UX 5.21    and 6.2    compilers, the Micro-
  6148.      port 286 compiler,    and the    Mark  Williams    compiler  on  the  Atari  ST.
  6149.      There  is    a  known  problem compiling under Aztec    C 4.10d    on the PC, if
  6150.      someone can figure    out what is going  wrong  it  would  be     appreciated.
  6151.      With that out of the way...
  6152.  
  6153.      This section describes the    "guts" of the Internet package for the    bene-
  6154.      fit   of  programmers   who   wish     to  write their own applications, or
  6155.      adapt the code to different hardware environments.    Potential application
  6156.      developers    should consider    strongly writing new applications for the NOS
  6157.      version of    the package, which is currently    in development.    Contact     Phil
  6158.      Karn  KA9Q    or Bdale Garbee    N3EUA for more information.  There will    *not*
  6159.      be    another    release    of the software    based on the internal structure     used
  6160.      through this release.
  6161.  
  6162.      The code as distributed includes both the    functions  of  an  IP  packet
  6163.      switch  and an  end-host  system,    including several servers. The imple-
  6164.      mentation is highly modular, however. For example,    if one wants to    build
  6165.      a    dedicated packet switch    without     any  local applications, the various
  6166.      applications and the TCP and UDP modules may easily be omitted  to     save
  6167.      space.
  6168.  
  6169.      The package allows    multiple simultaneous applications,  each  supporting
  6170.      multi-  ple   simultaneous      users,  each using TCP and/or    UDP. The only
  6171.      limit is memory space, which is getting quite tight on the     820;  the  C
  6172.      compiler  for  the     IBM   PC seems     to  generate  much more compact code
  6173.      (typically    1/2 as large as    for the    Z-80) so the PC    seems more  promising
  6174.      as    a large-scale server.
  6175.  
  6176.      8.6.1.  Data Structures
  6177.  
  6178.      To    increase portability, the pseudo-types "int16" and "int32"  are     used
  6179.      to     mean  an   unsigned   16-bit  integer    and  a signed 32-bit integer,
  6180.      respectively.  Ordi- narily these types are defined in machdep.h  to  be
  6181.      "unsigned int" and    "long".
  6182.  
  6183.      The various modules pass data  in    chained     structures   called   mbufs,
  6184.      with  the following format:
  6185.  
  6186.      struct mbuf {
  6187.      struct    mbuf *next;     /* Link mbufs belonging to single packets */
  6188.      struct    mbuf *anext;     /* Link packets on queues */
  6189.      char *data;         /* Ptr    to start of actual data    in buffer */
  6190.      int16 cnt;         /* Length of data in buffer */    };
  6191.  
  6192.      Although somewhat cumbersome to work with,    mbufs make  it    possible   to
  6193.      avoid  memory-to-memory copies that limit performance. For    example, when
  6194.      user data is transmitted it must first traverse several protocol  layers
  6195.      before  reaching  the  transmitter    hardware. With mbufs, each layer adds
  6196.      its protocol header by allo- cating an mbuf and linking it    to  the     head
  6197.      of    the mbuf "chain" given it by  the higher layer,    thus avoiding several
  6198.  
  6199.  
  6200.  
  6201.  
  6202.  
  6203.  
  6204.  
  6205.  
  6206.  
  6207.                       -    95 -
  6208.  
  6209.  
  6210.      copy operations.
  6211.  
  6212.      A number of primitives operating on mbufs are available in    mbuf.c.      The
  6213.      user  may     create,   fill,   empty  and  free  mbufs  himself  with the
  6214.      alloc_mbuf    and free_mbuf primitives, or at    the cost of a single  memory-
  6215.      to-memory    copy  he  he may use the more convenient qdata() and dqdata()
  6216.      primitives.
  6217.  
  6218.      8.6.2.  Timer Services
  6219.  
  6220.      TCP and IP    require    timers.    A timer    package     is  included,    so  the     user
  6221.      must  arrange  to call the    single entry point "tick" on a regular basis.
  6222.      The constant MSPTICK in  timer.h  should  be  defined  as    the  interval
  6223.      between   ticks   in  milliseconds.  One  second resolution is adequate.
  6224.      Since it can  trigger  a  considerable  amount  of     activity,  including
  6225.      upcalls  to user level, "tick" should not be called  from    an  interrupt
  6226.      handler. A    clock interrupt    should set  a  flag  which  will  then    cause
  6227.      "tick" to be called at user level.
  6228.  
  6229.      8.6.3.  Internet Type-of-Service
  6230.  
  6231.      One of the    features of the    Internet  is  the  ability  to    specify     pre-
  6232.      cedence  (i.e.,  priority)     on  a per-datagram basis. There are 8 levels
  6233.      of    precedence, with the bottom 6 defined by the DoD as  Routine,  Prior-
  6234.      ity,  Immediate,  Flash, Flash  Override  and  CRITICAL.  (Two  more are
  6235.      available for internal network functions).    For amateur use     we  can  use
  6236.      the  lower     four  as  Routine,  Welfare, Priority    and  Emergency.    Three
  6237.      more bits specify class of     service,  indicating  that  especially     high
  6238.      reliability,  high     throughput or low delay is  needed  for this connec-
  6239.      tion. Constants for this field are    defined    in internet.h.
  6240.  
  6241.      8.6.4.  The Internet Protocol Implementation.
  6242.  
  6243.      While the user does not ordinarily    see  this  level  directly,   it   is
  6244.      described here  for sake of completeness. Readers interested only in the
  6245.      interfaces    seen by    the applications programmer should skip     to  the  TCP
  6246.      and UDP sections.
  6247.  
  6248.      The IP implementation  consists  of  three     major    functions:  ip_route,
  6249.      ip_send and ip_recv.
  6250.  
  6251.      8.6.5.  IP    Gateway    (Packet    Router)    Support
  6252.  
  6253.      The first,    ip_route, is the IP packet switch. It takes a  single    argu-
  6254.      ment,  a pointer to the mbuf containing the IP datagram:
  6255.  
  6256.          void
  6257.          ip_route(bp,rxbroadcast)
  6258.          struct mbuf *bp;         /*    Datagram pointer */
  6259.          int rxbroadcast;         /*    Don't forward */
  6260.  
  6261.      All IP datagrams, coming or going,    pass through this   function.    After
  6262.      option  processing,   if    any,   the  datagram's destination address is
  6263.      extracted.    If it corresponds to the local host, it    is "kicked  upstairs"
  6264.  
  6265.  
  6266.  
  6267.  
  6268.  
  6269.  
  6270.  
  6271.  
  6272.  
  6273.                       -    96 -
  6274.  
  6275.  
  6276.      to     the upper half    of IP and  thence to the appropriate protocol module.
  6277.      Otherwise,    an internal routing table consulted to    determine  where  the
  6278.      datagram    should     be   forwarded.    The    routing     table    uses  hashing
  6279.      keyed on IP destination addresses,    called "tar-  gets".  If  the  target
  6280.      address is    not  found,  a    special     "default"  entry,  if available,  is
  6281.      used. If a    default    entry is not available either, an ICMP "Des- tination
  6282.      Unreachable" message containing the offending IP header  is  returned to
  6283.      the sender.
  6284.  
  6285.      The "rxbroadcast" flag is used to prevent forwarding of broadcast    pack-
  6286.      ets,   a  practice     which    might otherwise    result in spectacular routing
  6287.      loops. Any    subnet interface driver    receiving a packet addressed  to  the
  6288.      broadcast address    within that  subnet  MUST  set    this flag.  All    other
  6289.      packets (including    locally    ori- ginated packets) should  have  "rxbroad-
  6290.      cast" set to zero.
  6291.  
  6292.      ip_route ignores the IP destination address in broadcast packets,    pass-
  6293.      ing them up  to the appropriate higher level protocol which is also made
  6294.      aware of their broadcast nature. (TCP and ICMP ignore them; only UDP can
  6295.      accept them).
  6296.  
  6297.      Entries are added to the IP routing table with the    rt_add function:
  6298.  
  6299.      int      rt_add(target,gateway,metric,interface)       int32      target;
  6300.      /*    IP address of target */    int32 gateway;            /* IP addr of
  6301.      gateway to    reach  this  target  */     int  metric;               /*
  6302.      "cost"  metric,  for  routing  decisions */ struct    interface *interface;
  6303.      /*    device interface structure */
  6304.  
  6305.      "target" is the IP    address    of  the     destination;  it  becomes  the     hash
  6306.      index   key for subsequent    packet destination address lookups. If target
  6307.      ==    0, the default entry is    modified. "metric" is simply  stored  in  the
  6308.      table;  it     is  available    for  routing   cost   calculations   when  an
  6309.      automatic    routing    protocol is written.  "interface" is the address of a
  6310.      control  structure     for  the  particular  device to which    the  datagram
  6311.      should  be    sent; it is defined in the section "IP Inter- faces".
  6312.  
  6313.      rt_add returns 0 on success, -1 on    failure    (e.g., out of memory).
  6314.  
  6315.      To    remove an entry    from the routing table,     only  the   target   address
  6316.      need  be specified    to the rt_drop call:
  6317.  
  6318.          int
  6319.          rt_drop(target)
  6320.          int32 target;
  6321.  
  6322.      rt_drop returns 0 on success, -1 if the target could not be found.
  6323.  
  6324.      8.6.6.  IP    Interfaces
  6325.  
  6326.      Every lower level interface used to transmit IP datagrams must  have  an
  6327.      "inter- face" structure, defined as follows:
  6328.  
  6329.      /*    Interface control structure */
  6330.  
  6331.  
  6332.  
  6333.  
  6334.  
  6335.  
  6336.  
  6337.  
  6338.  
  6339.                       -    97 -
  6340.  
  6341.  
  6342.       struct interface {
  6343.          struct interface *next; /*    Linked list pointer */
  6344.          char *name;         /*    Ascii string with interface name */
  6345.          int16 mtu;             /*    Maximum    transmission unit size */
  6346.          int (*send)();         /*    Routine    to call    to send    datagram */
  6347.          int (*output)();         /*    Routine    to call    to send    raw packet */
  6348.          int (*recv)();         /*    Routine    to kick    to process input */
  6349.          int (*stop)();         /*    Routine    to call    before detaching */
  6350.          int16 dev;             /*    Subdevice number to pass to send */
  6351.          int16 flags;         /*    State of interface */
  6352.       #define IF_ACTIVE          0x01
  6353.       #define IF_BROADCAST    0x04    /* Interface is capable of broadcasting
  6354.      */    };
  6355.  
  6356.      Part of the interface structure is    for the    private    use  of     the   device
  6357.      driver.  "dev"  is     used to distinguish between one of several identical
  6358.      devices (e.g., serial links or radio channels) that might share the same
  6359.      send routine.
  6360.  
  6361.      A pointer to this structure kept in the  routing    table.     Two   fields
  6362.      in      the  interface   structure   are   examined  by ip_route: "mtu" and
  6363.      "send". The  maximum  transmission     unit  size  represents     the  largest
  6364.      datagram that  this  device  can handle; ip_route will do IP-level    frag-
  6365.      mentation as required to meet this     limit    before    calling     "send",  the
  6366.      function to  queue     datagrams  on    this  interface.  "send" is called as
  6367.      follows:
  6368.  
  6369.       (*send)(bp,interface,gateway,precedence,delay,throughput,reliability)
  6370.       struct mbuf *bp;              /* Pointer to datagram */
  6371.       struct interface *interface;    /* Interface structure */
  6372.       int32 gateway;              /* IP address of gateway */
  6373.       char precedence;              /* TOS bits from IP header */
  6374.       char delay;
  6375.       char throughput;
  6376.       char reliability;
  6377.  
  6378.      The "interface" and "gateway"  arguments  are  kept   in    the   routing
  6379.      table   and  passed  on  each  call  to  the send routine.    The interface
  6380.      pointer is    passed again because several interfaces    might share the     same
  6381.      output driver  (e.g.,  several identical  physical    channels).  "gateway"
  6382.      is    the IP address of the neighboring IP gateway on    the other end of  the
  6383.      link;  if    a  link-level  address is  required, the  send    routine     must
  6384.      map  this address either dynamically (e.g., with the Address  Resolution
  6385.      Protocol,    ARP)  or with a    static lookup table.  If the  link is  point-
  6386.      to-point, link-level addresses are    unnecessary, and the send routine can
  6387.      therefore ignore the gateway address.
  6388.  
  6389.      The Internet Type-of-Service (TOS)    bits  are  passed  to  the  interface
  6390.      driver   as  separate  arguments.    If  tradeoffs exist within the subnet
  6391.      between these various classes of service, the driver may use these    argu-
  6392.      ments  to    control     them    (e.g., optional    use of link level acknowledg-
  6393.      ments, priority queuing, etc.)
  6394.  
  6395.      It    is expected that the send routine will put a link level    header on the
  6396.  
  6397.  
  6398.  
  6399.  
  6400.  
  6401.  
  6402.  
  6403.  
  6404.  
  6405.                       -    98 -
  6406.  
  6407.  
  6408.      front of  the  packet, add    it an internal output queue, start output (if
  6409.      not already active) and return. It    must  NOT  busy-wait  for  completion
  6410.      (unless it    is a  very fast    device,    e.g., Ethernet)    since that blocks the
  6411.      entire system.
  6412.  
  6413.      Any interface that    uses ARP must also provide an "output"    routine.   It
  6414.      is      a  lower  level  entry  point    that allows the    caller to specify the
  6415.      fields in the link    header.    ARP uses it to    broadcast  a  request  for  a
  6416.      given  IP    address. It may    be  the     same  routine used internally by the
  6417.      driver to send IP datagrams once the link level fields have been  deter-
  6418.      mined. It is called as follows:
  6419.  
  6420.       (*output)(interface,dest,src,type,bp)
  6421.       struct interface *interface;    /* Pointer to interface structure    */
  6422.       char dest[];              /* Link level destination    address    */
  6423.       char src[];              /* Link level source address */
  6424.       int16 type;              /* Protocol type field for  link    level
  6425.      */
  6426.       struct mbuf *bp;              /* Data field (IP    datagram) */
  6427.  
  6428.      8.6.7.  IP    Host Support
  6429.  
  6430.      All of the    modules    described thus far are    required  in   all   systems.
  6431.      However,  the  routines  that  follow  are     necessary  only  if the sys-
  6432.      tem is to support higher-level applications. In a standalone IP  gateway
  6433.      (packet  switch)  without servers    or clients, the    following modules (IP
  6434.      user level, TCP and UDP) may be omitted to    allow  additional  space  for
  6435.      buffering;     define     the  flag  GWONLY  when compiling iproute.c to    avoid
  6436.      referencing the user level    half of    IP.
  6437.  
  6438.      The following function  is     called     by  iproute()    whenever  a  datagram
  6439.      arrives that is addressed to the local system.
  6440.  
  6441.       void
  6442.       ip_recv(bp,rxbroadcast)
  6443.       struct mbuf *bp;              /* Datagram */
  6444.       char rxbroadcast;              /* Incoming broadcast */
  6445.  
  6446.      ip_recv reassembles IP datagram fragments,    if necessary, and calls      the
  6447.      input  function   of   the      next     layer     protocol  (e.g.,  tcp_input,
  6448.      udp_input)    with the appropriate arguments,    as follows:
  6449.  
  6450.       (*protrecv)(bp,protocol,source,dest,tos,length,rxbroadcast);
  6451.       struct mbuf *bp;          /* Pointer to packet minus IP header */
  6452.       char protocol;          /* IP protocol ID    */
  6453.       int32 source;          /* IP address of sender */
  6454.       int32 dest;          /* IP address of destination (i.e,. us) */
  6455.       char tos;              /* IP type-of-service field in datagram */
  6456.       int16 length;          /* Length    of datagram minus IP header */
  6457.       char rxbroadcast;          /* Incoming broadcast */
  6458.  
  6459.      The list of protocols is contained    in a  switch()     statement   in      the
  6460.      ip_recv  function.     If  the  protocol  is    unsupported, an    ICMP Protocol
  6461.      Unreachable message is returned to    the sender unless the packet came  in
  6462.  
  6463.  
  6464.  
  6465.  
  6466.  
  6467.  
  6468.  
  6469.  
  6470.  
  6471.                       -    99 -
  6472.  
  6473.  
  6474.      as     a  broadcast.     Higher     level    protocols such as TCP and UDP use the
  6475.      ip_send routine to    generate  IP  datagrams.  The  arguments  to  ip_send
  6476.      correspond     directly  to fields in    the IP header, which is    generated and
  6477.      put in front of the user's     data  before  being handed to ip_route:
  6478.  
  6479.       ip_send(source,dest,protocol,tos,ttl,bp,length,id,df)
  6480.       int32 source;          /* source    address    */
  6481.       int32 dest;          /* Destination address */
  6482.       char protocol;          /* Protocol */
  6483.       char tos;              /* Type of service */
  6484.       char ttl;              /* Time-to-live */
  6485.       struct mbuf *bp;          /* Data portion of datagram */
  6486.       int16 length;          /* Optional length of data portion */
  6487.       int16 id;              /* Optional identification */
  6488.       char df;              /* Don't-fragment    flag */
  6489.  
  6490.      This interface is modeled very closely after the example given  on     page
  6491.      32     of RFC-791.  Zeros  may be passed for id or ttl, and system defaults
  6492.      will be pro- vided. If zero is passed for length, it will be  calculated
  6493.      automatically.
  6494.  
  6495.      8.6.8.  The Transmission Control Protocol (TCP)
  6496.  
  6497.      A TCP connection is  uniquely  identified    by   the   concatenation   of
  6498.      local   and remote     "sockets".  In     turn,    a  socket  consists of a host
  6499.      address (a    32-bit integer)    and a TCP port (a 16-bit integer), defined by
  6500.      the C structure
  6501.  
  6502.       struct socket {
  6503.          long address;   /*    32-bit IP address */
  6504.          short port;     /*16-bit TCP port */
  6505.       };
  6506.  
  6507.      It    is therefore possible to have several simultaneous but distinct     con-
  6508.      nections  to   the     same  port on a given machine,    as long    as the remote
  6509.      sockets are dis- tinct. Port numbers are assigned either through  mutual
  6510.      agreement,     or more com- monly  when  a  "standard" service is involved,
  6511.      as    a "well    known port"  number.   For  example,   to   obtain   standard
  6512.      remote  login  service  using  the     TELNET    presentation-layer  protocol,
  6513.      by     convention you    initiate a connection to TCP port 23;  to  send     mail
  6514.      using  the    Simple Mail Transfer Protocol (SMTP) you  con- nect  to     port
  6515.      25. ARPA maintains    port number lists and  periodically  publishes    them;
  6516.      the latest    revision is RFC-960,  "Assigned     Numbers".   They  will     also
  6517.      assign  port  numbers  to    a new application on request if    it appears to
  6518.      be    of general interest.
  6519.  
  6520.      TCP connections are best modeled as a pair     of  one-way  paths  (one  in
  6521.      each  direction)  rather  than  single  full-duplex paths.    A TCP "close"
  6522.      really means "I have no more data to send". Station A may close its path
  6523.      to     station  B   leaving the  reverse  path  from    B  to A    unaffected; B
  6524.      may continue to send data to A indefinitely until it too closes its half
  6525.      of    the  connection.   Even     after    a user initiates a close, TCP contin-
  6526.      ues to retransmit any unacknowledged data if necessary to ensure that it
  6527.      reaches  the  other  end. This is known as     "graceful close" and greatly
  6528.  
  6529.  
  6530.  
  6531.  
  6532.  
  6533.  
  6534.  
  6535.  
  6536.  
  6537.                      - 100 -
  6538.  
  6539.  
  6540.      simplifies    certain    applications such as FTP.
  6541.  
  6542.      This package is written as    a "module" intended to be compiled and linked
  6543.      with  the    application(s)    so that    they can be run    as one program on the
  6544.      same machine.  This greatly simplifies  the  user/TCP  interface,    which
  6545.      becomes  just   a     set   of  internal   subroutine   calls  on a single
  6546.      machine. The internal TCP state (e.g.,  the  address   of     the   remote
  6547.      station)    is   easily  accessed.    Reliability  is    improved,  since  any
  6548.      hardware  failure    that  kills TCP    will  likely  take  its     applications
  6549.      with  it  anyway.    Only  IP  datagrams  flow  out of the machine  across
  6550.      hardware  interfaces  (such  as asynch RS-232 ports or whatever else  is
  6551.      avail-  able)  so    hardware flow control or  complicated  host/front-end
  6552.      protocols    are unnecessary.
  6553.  
  6554.      The TCP supports five basic  operations  on  a   connection:   open_tcp,
  6555.      send_tcp,    receive_tcp,  close_tcp     and  del_tcp. A sixth,    state_tcp, is
  6556.      provided mainly for debugging. Since this TCP module cannot  assume  the
  6557.      presence  of a  sleep/wakeup facility from    the underlying operating sys-
  6558.      tem, functions that would ordinarily block    (e.g., recv_tcp    when no     data
  6559.      is     available)  instead  set  net_error to     the constant  EWOULDBLK  and
  6560.      immediately return    -1.  Asynchronous notification of events such as data
  6561.      arrival   can   be      obtained   through  the  upcall  facility described
  6562.      earlier.
  6563.  
  6564.      Each TCP function is summarized in    the following section  in  the     form
  6565.      of     C declarations    and descriptions of each argument.
  6566.  
  6567.      int net_error;
  6568.  
  6569.      This global variable stores the specific cause of an error    from  one  of
  6570.      the  TCP  or  UDP functions. All functions    returning integers (i.e., all
  6571.      except open_tcp) return -1    in the    event  of  an  error,  and  net_error
  6572.      should  be     examined  to determine     the  cause. The  possible errors are
  6573.      defined as    constants in the header    file netuser.h.
  6574.  
  6575.       /* Open a    TCP connection */
  6576.       struct tcb *
  6577.       open_tcp(lsocket,fsocket,mode,window,r_upcall,t_upcall,s_upcall,tos,user)
  6578.       struct socket *lsocket; /* Local socket */
  6579.       struct socket *fsocket; /* Remote    socket */
  6580.       int mode;              /* Active/passive/server */
  6581.       int16 window;          /* Receive window    (and send buffer) sizes    */
  6582.       void (*r_upcall)();     /* Function to call when data arrives */
  6583.       void (*t_upcall)();     /* Function to call when ok to send  more     data
  6584.      */
  6585.       void (*s_upcall)();     /*  Function  to    call  when  connection    state
  6586.      changes */
  6587.       char tos;              /* Internet Type-of-Service */
  6588.       int *user;          /* Pointer for convenience of user */
  6589.  
  6590.      "lsocket" and "fsocket" are pointers to the local and  foreign  sockets,
  6591.      respec- tively.
  6592.  
  6593.      "mode" may    take on    three  values,    all   defined    in   net.user.h.   If
  6594.  
  6595.  
  6596.  
  6597.  
  6598.  
  6599.  
  6600.  
  6601.  
  6602.  
  6603.                      - 101 -
  6604.  
  6605.  
  6606.      mode   is    TCP_PASSIVE,  no packets are sent, but a TCP control block is
  6607.      created that will accept a    subsequent active open from another TCP. If a
  6608.      specific  foreign    socket is  passed  to  a  passive  open, then connect
  6609.      requests from any other foreign socket will be rejected. If the  foreign
  6610.      socket  fields  are  set  to  zero,  or  if fsocket  is  NULLSOCK,     then
  6611.      connect requests from any foreign socket will be accepted.     If  mode  is
  6612.      TCP_ACTIVE,  TCP  will  initiate a    connection to  a  remote socket     that
  6613.      must already have been created in the LISTEN state    by its    client.      The
  6614.      foreign  socket  must  be    completely specified in    an active open.     When
  6615.      mode is TCP_SERVER, open_tcp behaves as  though  TCP_PASSIVE  was    given
  6616.      except  that  an internal "clone" flag is set. When a connection request
  6617.      comes in, a fresh copy of    the  TCP  control  block  is created and  the
  6618.      original  is  left    intact.    This allows multiple sessions to exist simul-
  6619.      taneously;     if  TCP_PASSIVE  were    used instead only the  first  connect
  6620.      request would be accepted.
  6621.  
  6622.      "r_upcall", "t_upcall" and     "s_upcall"  provide   optional      upcall   or
  6623.      pseudo-  interrupt      mechanisms  useful  when running in a    non operating
  6624.      system environ- ment.  Each of the     three    arguments,  if    non-NULL,  is
  6625.      taken  as    the address of    a user-supplied    function to call when receive
  6626.      data arrives, transmit queue space    becomes    available, or the  connection
  6627.      state  changes.  The   three   functions    are called with    the following
  6628.      arguments:
  6629.  
  6630.       (*r_upcall)(tcb,count); /* count == number of bytes in receive queue */
  6631.       (*t_upcall)(tcb,avail); /* avail == space    available in send queue    */
  6632.       (*s_upcall)(tcb,oldstate,newstate);
  6633.  
  6634.      Note: whenever a single event invokes more    than one upcall    the order  in
  6635.      which  the    upcalls    are made is not    strictly defined. In general, though,
  6636.      the Principle of Least Astonishment is followed.    E.g.,  when  entering
  6637.      the   ESTABLISHED    state, the state change    upcall is invoked first, fol-
  6638.      lowed by the transmit upcall.   When   an     incoming   segment  contains
  6639.      both   data   and    FIN, the receive upcall    is invoked first, followed by
  6640.      the state change to CLOSE_WAIT state.  In this case, the user may inter-
  6641.      pret this state change as a "end of file" indicator.
  6642.  
  6643.      "tos" is the Internet type-of-service field. This    parameter  is  passed
  6644.      along  to    IP   and is included in    every datagram.    The actual precedence
  6645.      value used    is the higher of the two specified in the corresponding     pair
  6646.      of    open_tcp calls.
  6647.  
  6648.      open_tcp returns a    pointer    to an internal Transmission   Control    Block
  6649.      (tcb).  This "magic cookie" must be passed    back as    the first argument to
  6650.      all other TCP calls. In event of error, the NULL pointer (0) is returned
  6651.      and  net_error  is    set to the reason for the error.
  6652.  
  6653.      The only limit on the number of  TCBs  that  may  exist  at   any     time
  6654.      (i.e.,   the number  of  simultaneous  connections)  is  the  amount  of
  6655.      free memory on the    machine. Each TCB on  a     16-bit     processor  currently
  6656.      takes  up     111   bytes;    addi-  tional    memory    is consumed and    freed
  6657.      dynamically as needed to buffer send and receive data.  Deleting  a  TCB
  6658.      (see the del_tcp()    call) reclaims its space.
  6659.  
  6660.  
  6661.  
  6662.  
  6663.  
  6664.  
  6665.  
  6666.  
  6667.  
  6668.  
  6669.                      - 102 -
  6670.  
  6671.  
  6672.       /* Send data on a    TCP connection */
  6673.       int
  6674.       send_tcp(tcb,bp)
  6675.       struct tcb *tcb;          /* TCB pointer */
  6676.       struct mbuf *bp;          /* Pointer to user's data    mbufs */
  6677.  
  6678.      "tcb" is the pointer returned by the  open_tcp()    call.    "bp"   points
  6679.      to      the  user's    mbuf   with   data  to be sent.    After being passed to
  6680.      send_tcp, the user    must no    longer access the data buffer. TCP uses    posi-
  6681.      tive acknowledgments  with    retransmission    to  ensure in-order delivery,
  6682.      but this is largely invisible to the user.    Once the remote    TCP has     ack-
  6683.      nowledged the data, the  buffer  will  be freed automatically.
  6684.  
  6685.      TCP does not enforce a limit in  the  number  of  bytes  that   may   be
  6686.      queued  for transmission,    but  it     is  recommended that the application
  6687.      not send any more than the    amount passed as  "cnt"     in  the  transmitter
  6688.      upcall.   The  package  uses shared,  dynamically allocated buffers, and
  6689.      it    is entirely possible for a mis-    behaving user task to run the  system
  6690.      out of buffers.
  6691.  
  6692.       /* Receive data on a TCP connection */
  6693.       int
  6694.       recv_tcp(tcb,bp,cnt)
  6695.       struct tcb *tcb;
  6696.       struct mbuf **bp;
  6697.       int16 cnt;
  6698.  
  6699.      recv_tcp()    passes back through bp a pointer to an mbuf  chain   contain-
  6700.      ing   any    available  receive  data, up to    a maximum of "cnt" bytes. The
  6701.      actual number of bytes received (the lesser of  "cnt"  and     the   number
  6702.      pending   on   the     receive queue)    is returned. If    no data    is available,
  6703.      net_error is set to EWOULDBLK and -1 is returned; the r_upcall mechanism
  6704.      may  be   used   to   determine   when  data arrives.  (Technical    note:
  6705.      "r_upcall"    is called whenever a PUSH or FIN bit is    seen in     an  incoming
  6706.      segment,  or  if  the receive  window  fills.  It    is  called before  an
  6707.      ACK  is  sent back    to the remote TCP, in  order  to  give    the  user  an
  6708.      opportunity to piggyback any data in response.)
  6709.  
  6710.      When the remote TCP closes    its half of the     connection  and  all    prior
  6711.      incoming  data   has   been  read by the local user, subsequent calls to
  6712.      recv_tcp return 0 rather than -1 as an "end of transmission"  indicator.
  6713.      Note   that   the     local application  is    notified  of  a     remote    close
  6714.      (i.e., end-of-file) by a state- change upcall with    the new     state    being
  6715.      CLOSE_WAIT;  if   the  local  application has  closed  first,  a  remote
  6716.      close is indicated     by  a    state-change  upcall  to  either  CLOSING  or
  6717.      TIME_WAIT    state. (CLOSING    state is used only  when  the  two ends    close
  6718.      simultaneously and    their FINs cross in the    mail).
  6719.  
  6720.       /* Close a TCP connection    */
  6721.       close_tcp(tcb)
  6722.       struct tcb *tcb;
  6723.  
  6724.      This tells    TCP that the local user    has no more  data   to     send.     How-
  6725.      ever,   the  remote  TCP  may  continue to    send data indefinitely to the
  6726.  
  6727.  
  6728.  
  6729.  
  6730.  
  6731.  
  6732.  
  6733.  
  6734.  
  6735.                      - 103 -
  6736.  
  6737.  
  6738.      local user, until the remote user also does a close_tcp.  An attempt  to
  6739.      send data after a    close_tcp is an    error.
  6740.  
  6741.       /* Delete    a TCP connection */
  6742.       del_tcp(tcb)
  6743.       struct tcb *tcb;
  6744.  
  6745.      When the connection has been closed in both connections and all incoming
  6746.      data  has been read, this call is made to cause TCP to reclaim the    space
  6747.      taken up by the TCP control block.    Any incoming data remaining unread is
  6748.      lost.
  6749.  
  6750.       /* Dump a    TCP connection state */
  6751.       state_tcp(tcb)
  6752.       struct tcb *tcb;
  6753.  
  6754.      This debugging call prints    an ASCII-format    dump of     the  TCP  connection
  6755.      state  on the  terminal.  You need    a copy of the TCP specification    (ARPA
  6756.      RFC 793 or    MIL- STD-1778) to interpret most of the    numbers.
  6757.  
  6758.      8.6.9.  The User Datagram Protocol    (UDP)
  6759.  
  6760.      UDP is available for simple applications not needing the services of   a
  6761.      reli-  able  protocol  like TCP.  A minimum of overhead is    placed on top
  6762.      of    the "raw" IP datagram service, consisting only of port numbers and  a
  6763.      checksum    covering  the  UDP  header  and    user data. Four    functions are
  6764.      available to the UDP user.
  6765.  
  6766.       /* Create    a UDP control block for    lsocket, so that we can    queue
  6767.        * incoming datagrams.
  6768.        */
  6769.       int
  6770.       open_udp(lsocket,r_upcall)
  6771.       struct socket *lsocket;
  6772.       void (*r_upcall)();
  6773.  
  6774.      open_udp creates a    queue to accept    incoming  datagrams  (regardless   of
  6775.      source)  addressed      to  "lsocket".  "r_upcall"  is  an  optional upcall
  6776.      mechanism to provide the address of a function to be called  as  follows
  6777.      whenever a    datagram arrives:
  6778.  
  6779.       (*r_upcall)(lsocket,rcvcnt);
  6780.       struct socket *lsocket;          /* Pointer to local socket */
  6781.       int rcvcnt;              /* Count of datagrams pending on    queue
  6782.      */
  6783.  
  6784.       /* Send a    UDP datagram */
  6785.       int
  6786.       send_udp(lsocket,fsocket,tos,ttl,bp,length,id,df)
  6787.       struct socket *lsocket;          /* Source    socket */
  6788.       struct socket *fsocket;          /* Destination socket */
  6789.       char tos;                  /* Type-of-service for IP    */
  6790.       char ttl;                  /* Time-to-live for IP */
  6791.       struct mbuf *bp;              /* Data field, if    any */
  6792.  
  6793.  
  6794.  
  6795.  
  6796.  
  6797.  
  6798.  
  6799.  
  6800.  
  6801.                      - 104 -
  6802.  
  6803.  
  6804.       int16 length;              /* Length    of data    field */
  6805.       int16 id;                  /* Optional ID field for IP */
  6806.       char df;                  /* Don't Fragment    flag for IP */
  6807.  
  6808.      The parameters passed to send_udp    are  simply  stuffed   in   the      UDP
  6809.      and  IP headers, and the datagram is sent on its way.
  6810.  
  6811.       /* Accept    a waiting datagram, if available. Returns length of  datagram
  6812.      */
  6813.       int
  6814.       recv_udp(lsocket,fsocket,bp)
  6815.       struct socket *lsocket;          /* Local socket to receive on */
  6816.       struct socket *fsocket;          /* Place to stash    incoming socket    */
  6817.       struct mbuf **bp;              /* Place to stash    data packet */
  6818.  
  6819.      The "lsocket" pointer indicates  the   socket   the   user      wishes   to
  6820.      receive   a datagram  on (a queue must have been created previously with
  6821.      the open_udp rou- tine). "fsocket"    is taken as the    address    of  a  socket
  6822.      structure    to  be    overwrit-  ten    with  the  foreign  socket associated
  6823.      with the datagram being read; bp is overwritten with a  pointer  to  the
  6824.      data portion (if any) of the datagram  being received.
  6825.  
  6826.       /* Delete    a UDP control block */
  6827.       int
  6828.       del_udp(lsocket)
  6829.       struct socket *lsocket;
  6830.  
  6831.      This function destroys any    unread datagrams on a queue, and reclaims the
  6832.      space taken by the    queue descriptor.
  6833.  
  6834.  
  6835.  
  6836.  
  6837.  
  6838.  
  6839.  
  6840.  
  6841.  
  6842.  
  6843.  
  6844.  
  6845.  
  6846.  
  6847.  
  6848.  
  6849.  
  6850.  
  6851.  
  6852.  
  6853.  
  6854.  
  6855.  
  6856.  
  6857.  
  6858.  
  6859.  
  6860.  
  6861.  
  6862.  
  6863.  
  6864.  
  6865.  
  6866.  
  6867.  
  6868.  
  6869.  
  6870.                      CONTENTS
  6871.  
  6872.  
  6873.  
  6874.      Section Title                             Page
  6875.  
  6876.      1.     Introduction to TCP/IP    and the    KA9Q Software                3
  6877.      1.1.  An Overview of the TCP/IP Protocol Family                       3
  6878.      1.1.1.  Acknowledgement                                               3
  6879.      1.1.2.  Introduction                            3
  6880.      1.1.3.  What is TCP/IP?                             3
  6881.      1.1.4.  General description of the    TCP/IP protocols                   8
  6882.      1.1.5.  The IP level                                                 12
  6883.      1.1.6.  The Ethernet level                                           13
  6884.      1.1.7.  Well-known sockets and the applications layer           15
  6885.      1.1.8.  An    example    application: SMTP                                 17
  6886.      1.2.  Protocols other than    TCP: UDP and ICMP                         20
  6887.      1.3.  Keeping track of names and information: the domain system      21
  6888.      1.4.  Routing                                                        22
  6889.      1.5.  Details about Internet addresses: subnets and broadcasting     24
  6890.      1.6.  Datagram fragmentation and reassembly                          26
  6891.      1.7.  Ethernet encapsulation: ARP                                    26
  6892.      1.8.  Getting more information                                       27
  6893.      1.9.  Overview of the KA9Q    Internet Package                          29
  6894.  
  6895.      2.     Installation                                                     31
  6896.      2.1.  What an IP Address Is, and How to Get One                      31
  6897.      2.2.  Configuring a TNC for TCP/IP    Operation                         31
  6898.      2.2.1.  TAPR TNC-1 and Clones                                        31
  6899.      2.2.2.  TAPR TNC-2 and Clones                                        32
  6900.      2.2.3.  AEA PK-232                                                   32
  6901.      2.2.4.  Kantronics    TNC's                                             33
  6902.      2.2.5.  Paccomm PC-100 Card                                          34
  6903.      2.2.6.  DRSI                                                         34
  6904.      2.3.  IBM PC and Clones                                              34
  6905.      2.3.1.  Installing    the Plug'N'Play    Disk                              34
  6906.      2.3.1.1.  The AUTOEXEC.NET    File                                      34
  6907.      2.3.1.2.  The FTPUSERS File                                          35
  6908.      2.3.1.3.  The HOSTS.NET File                                         36
  6909.      2.3.2.  Installing on a Hard Disk                                    37
  6910.      2.4.  Unix                                                              37
  6911.      2.5.  Macintosh                                                      38 
  6912.      2.6.  Atari ST                                                       38
  6913.      2.7.  NEC PC-9801                                                    38
  6914.      2.8.  Hewlett-Packard Portable Plus                                  38
  6915.  
  6916.      3.     Taking    NET for    a Test Drive                                      39
  6917.      3.1.  Trying out the AX.25 Support                                   39
  6918.      3.2.  The Telnet Command                                             39
  6919.      3.3.  The FTP Command                                                40
  6920.      3.4.  The Mail System                                                40
  6921.      3.5.  Tracing and Status Commands                                      40
  6922.  
  6923.      4.     The Mail System                                                  42
  6924.      4.1.  Installing and Using BM                                        42
  6925.      4.1.1.  Installation                                                 42
  6926.      4.1.1.1.  Directory Structure                                        42
  6927.      4.1.1.2.  Configuration File                                         42
  6928.      4.1.1.2.1.  smtp <path>                                              43
  6929.      4.1.1.2.2.     host <your hostname>                                     43
  6930.      4.1.1.2.3.  user <username>                                          43
  6931.      4.1.1.2.4.     edit <path of your editor>                               43
  6932.      4.1.1.2.5.     fullname <your    full name>                                43
  6933.      4.1.1.2.6.     reply <return address>                                      43
  6934.      4.1.1.2.7.     maxlet    <number    of messages>                              43
  6935.      4.1.1.2.8.     mbox <filename>                                          43
  6936.      4.1.1.2.9.     record    <filename>                                        44
  6937.      4.1.1.2.10.  folder <directory name>                                 44
  6938.      4.1.1.2.11.  screen [bios|direct]                                    44
  6939.      4.1.1.2.12.  Example BM.RC File                                      44
  6940.      4.1.1.3.  The alias File                                             44
  6941.      4.1.1.4.  /spool/mqueue/sequence.seq                                 45
  6942.      4.1.2.  Environment                                                  45
  6943.      4.2.  Commands                                                       45
  6944.      4.2.1.  Main Menu Commands                                           45
  6945.      4.2.1.1.  m [userlist]                                               45
  6946.      4.2.1.2.  d [msglist]                                                45
  6947.      4.2.1.3.  h                                                          45
  6948.      4.2.1.4.  u [msglist]                                                46
  6949.      4.2.1.5.  n [mailbox]                                                46
  6950.      4.2.1.6.  ! cmd                                                      46
  6951.      4.2.1.7.  ?                                                          46
  6952.      4.2.1.8.  s [msglist] [file]                                         46
  6953.      4.2.1.9.  p [msglist]                                                46
  6954.      4.2.1.10.    w [msglist] file                                          46
  6955.      4.2.1.11.  f [msg]                                                   46
  6956.      4.2.1.12.    b [msg]                                                      46
  6957.      4.2.1.13.  r [msg]                                                   47
  6958.      4.2.1.14.  msg#                                                      47
  6959.      4.2.1.15.    l                                                         47
  6960.      4.2.1.16.  k [msglist]                                               47
  6961.      4.2.1.17.  $                                                         47
  6962.      4.2.1.18.    x                                                         47
  6963.      4.2.1.19.  q                                                         47
  6964.      4.2.2.  Text Input Commands                                          47
  6965.      4.2.3.  Command Line Options                                         48
  6966.      4.3.  Technical Information                                          48
  6967.      4.3.1.  Outbound Mail Queue File Formats                             48
  6968.      4.3.2.  Standards Documents                                          48
  6969.      4.4.  Bug Reports                                                    49
  6970.  
  6971.      5.     NET/ROM Support                                                  50
  6972.      5.1.  Introduction                                                   50
  6973.      5.2.  Setting up the NET/ROM Interface                               50
  6974.      5.3.  Tracing on the NET/ROM Interface                               50
  6975.      5.4.  Routing Broadcasts                                             50
  6976.      5.5.  The NET/ROM Routing Table                                      51
  6977.      5.6.  The Importance of the Routing Table                            52
  6978.      5.7.  Interfacing with NET/ROMs Using Your    Serial Port               53
  6979.      5.8.  The Time to Live Initializer                                      53
  6980.      5.9.  Using NET/ROM Support for IP                                      53
  6981.      5.10.  The    NET/ROM    Transport Layer                                      54
  6982.      5.11.  Connecting via NET/ROM Transport                              55
  6983.      5.12.  Displaying the Status of NET/ROM Connections                  55
  6984.      5.13.  NET/ROM Transport Parameters                                  55
  6985.      5.14.  The Mailbox                                                   56
  6986.      5.15.  Where to go    for More Information                              56
  6987.      5.16.  About the Code                                                56
  6988.  
  6989.      6.     Advanced Topics                                                  58
  6990.      6.1.  The Finger Server                                              58
  6991.      6.2.  The GRAPES Multi-Port Digipeating Code                         58
  6992.      6.3.  Multiple Serial Ports on One    Interrupt                         59
  6993.  
  6994.      7.     NET Command Reference                                            60
  6995.      7.1.  Startup                                                        60
  6996.      7.2.  Console Mode                                                   60
  6997.      7.3.  Commands                                                       60
  6998.      7.3.1.  <cr>                                                         61
  6999.      7.3.2.  !                                                            61
  7000.      7.3.3.  #                                                            61
  7001.      7.3.4.  arp                                                          61
  7002.      7.3.4.1.  arp add <hostid>    ether|ax25|netrom <ether addr|callsign>      61
  7003.      7.3.4.2.  arp drop    <hostid> ether|ax25|netrom                        61
  7004.      7.3.4.3.  arp publish                                                61
  7005.      7.3.5.  attach                                                       61
  7006.      7.3.5.1.  HP Portable Specifics                                      63
  7007.      7.3.5.2.  SLIP Modem Dialing                                         63
  7008.      7.3.6.  ax25                                                         64
  7009.      7.3.6.1.  ax25 digipeat [on|off]                       64
  7010.      7.3.6.2.  ax25 heard [on|off]                       64
  7011.      7.3.6.3.  ax25 maxframe [<val]>]                       64
  7012.      7.3.6.4.  ax25 mycall [<call>]                       64
  7013.      7.3.6.5.  ax25 bbscall [<call>]                       64
  7014.      7.3.6.6.  ax25 paclen [<val>]                       64
  7015.      7.3.6.7.  ax25 pthresh [<val>]                       65
  7016.      7.3.6.8.  ax25 reset <axcb>                       65
  7017.      7.3.6.9.  ax25 retry [<val>]                       65
  7018.      7.3.6.10.  ax25 status [<axcb>]                       65
  7019.      7.3.6.11.    ax25 t1|t2|t3 [<val>]                       65
  7020.      7.3.6.12.  ax25 window [<val>]                       65
  7021.  
  7022.      7.3.7.  close [<session #>]                       65
  7023.      7.3.8.  connect <interface> <callsign> [<digipeater> ... ]          65
  7024.      7.3.9.  dir [<dirname>]                           66
  7025.      7.3.10.  disconnect [<session #>]                                    66
  7026.      7.3.11.  echo [accept|refuse]                                        66
  7027.      7.3.12.  eol [unix|standard]                                         66
  7028.      7.3.13.  escape <char>                                               67
  7029.      7.3.14.  etherstat                                                   67
  7030.      7.3.15.  exit                                                        67
  7031.      7.3.16.  finger                                                      67
  7032.      7.3.17.  ftp <hostid>                                                67
  7033.      7.3.17.1.  abort                                                     67
  7034.      7.3.17.2.    dir [<file>|<directory>    [<localfile>]]                    67
  7035.      7.3.17.3.    get <remote_file> [<local_file>]                          68
  7036.      7.3.17.4.    ls [<file>|<directory> [<localfile>]]                     68
  7037.      7.3.17.5.    mkdir <remote_directory>                                  68
  7038.      7.3.17.6.    put <local_file> [<remote_file>]                          68
  7039.      7.3.17.7.    rmdir <remote_directory>                                  68
  7040.      7.3.17.8.    type [a|i|l<bytesize>]                                    68
  7041.      7.3.18.  help                                                        69
  7042.      7.3.19.  hostname [<name>]                                              69
  7043.      7.3.20.  log [stop|<file>]                                           69
  7044.      7.3.21.  ip                                                          69
  7045.      7.3.21.1.  ip address [<hostid>]                                     69
  7046.      7.3.21.2.    ip status                                                 69
  7047.      7.3.21.3.    ip ttl [<val>]                                            69
  7048.      7.3.22.  memstat                                                     69
  7049.      7.3.23.  mode <interface> [vc|datagram]                              69
  7050.      7.3.24.  mulport [on|off]                                            70
  7051.      7.3.25.  param <interface>    [param]                                      71
  7052.      7.3.26.  pwd [<dirname>]                                             71
  7053.      7.3.27.  record [<filename>|off]                                     71
  7054.      7.3.28.  reset [<session>]                                           71
  7055.      7.3.29.  route                                                       71
  7056.      7.3.30.  session [<session #>]                                      72
  7057.      7.3.31.  shell                                                       73
  7058.      7.3.32.  smtp                                                        73
  7059.      7.3.32.1.  smtp gateway [<hostid>]                                   73
  7060.      7.3.32.2.    smtp kick                                                 73
  7061.      7.3.32.3.  smtp maxclients [<val>]                                   73
  7062.      7.3.32.4.    smtp timer [<val>]                                        73
  7063.      7.3.32.5.    smtp trace [<val>]                                        73
  7064.      7.3.33.  start                                                       73
  7065.      7.3.34.  stop                                                      74
  7066.      7.3.35.  tcp                                                         74
  7067.      7.3.35.1.    tcp irtt [<val>]                                          74
  7068.      7.3.35.2.  tcp kick <tcp_addr>                                       74
  7069.      7.3.35.3.    tcp mss    [<size>]                                         74
  7070.      7.3.35.4.  tcp reset <tcb_addr>                       74
  7071.      7.3.35.5.    tcp rtt    <tcp_addr> <rtval>                                74
  7072.      7.3.35.6.    tcp status [<tcb_addr>]                                      74
  7073.      7.3.35.7.    tcp window [<val>]                                        75
  7074.      7.3.36.  telnet <hostid>                                             75
  7075.      7.3.37.  trace [<interface> [<flags>]|allmode|cmdmode]               75
  7076.      7.3.38.  udp status                                                  75 
  7077.      7.3.39.  upload [<filename>]                                         75 
  7078.      7.3.40.  ?                                   75
  7079.  
  7080.      8.     Appendices                                                       76
  7081.      8.1.  Obtaining Current Bits                       76
  7082.      8.1.1.  Via FTP on    the Internet                       76
  7083.      8.1.2.  On PC Floppies                           76
  7084.      8.1.2.1.  WB3FFV's    Phone BBS in the USA                    76
  7085.      8.1.2.2.  PA0GRI's    Phone BBS in Holland                   77
  7086.      8.1.3.  Gary Sanders' Phone BBS in    the USA                  77
  7087.      8.1.4.  Michael Broqvist in Sweden                      77
  7088.      8.2.  The KISS Specification                       78
  7089.      8.3.  The KISS Host to TNC    Protocol                   78
  7090.      8.3.1.  The Protocol Specification                      78
  7091.      8.3.1.1.  Introduction                           78
  7092.      8.3.1.2.  Asynchtronous Frame Format                   78
  7093.      8.3.1.2.1.  Transparency                           79
  7094.      8.3.1.3.  Control of the Raw TNC                       79
  7095.      8.3.1.4.  Persistence                           80
  7096.      8.3.2.  The TNC-2 Implementation                       80
  7097.      8.3.3.  The TNC-1 Implementation                       81
  7098.      8.3.4.  The VADCG/ASHBY Implementation                   81
  7099.      8.3.5.  The AEA Implemenation                       81
  7100.      8.3.6.  The Kantronics Implemenation                   81
  7101.      8.4.  The FTP, Inc., Packet Driver    Specification                81
  7102.      8.4.1.  Introduction and Motivation                   81
  7103.      8.4.2.  Identifying network interfaces                   82
  7104.      8.4.3.  Initiating    driver operations                   83 
  7105.      8.4.4.  Programming interface                       83
  7106.      8.4.4.1.  Entry Conditions                           84
  7107.      8.4.4.2.  Byte ordering                           84
  7108.      8.4.4.3.  driver_info()                           84
  7109.      8.4.4.4.  access_type()                           85
  7110.      8.4.4.5.  release_type()                           86
  7111.      8.4.4.6.  send_pkt()                           86
  7112.      8.4.4.7.  terminate()                           87
  7113.      8.4.4.8.  get_address()                           87
  7114.      8.4.4.9.  reset_interface()                       87
  7115.      8.4.4.10.    set_rcv_mode()                           88
  7116.      8.4.4.11.  get_rcv_mode()                           89
  7117.      8.4.4.12.    set_multicast_list()                       89
  7118.      8.4.4.13.  get_multicast_list()                       89
  7119.      8.4.4.14.    get_statistics()                       90
  7120.      8.4.4.15.  set_address()                           90
  7121.      8.4.5.  Interface classes and types                   91
  7122.      8.4.6.  Function call numbers                       92
  7123.      8.4.7.  Error codes                           92
  7124.      8.4.8.  802.3 vs. Blue Book Ethernet                   93
  7125.      8.5.  Information for Software Developers                   93
  7126.      8.6.  Technical Information for Client/Server Developers           94
  7127.      8.6.1.  Data Structures                           94
  7128.      8.6.2.  Timer Services                           95
  7129.      8.6.3.  Internet Type-of-Service                       95
  7130.      8.6.4.  The Internet Protocol Implementation.                95
  7131.      8.6.5.  IP    Gateway    (Packet    Router)    Support                  95
  7132.      8.6.6.  IP    Interfaces                           96
  7133.      8.6.7.  IP    Host Support                           98
  7134.      8.6.8.  The Transmission Control Protocol (TCP)               99
  7135.      8.6.9.  The User Datagram Protocol    (UDP)                  103
  7136.  
  7137.